[packman] [RFC] Main Dependency Portability was: Re: ffmpeg update to version 2.0
Manfred Tremmel
manfred at links2linux.de
Sun Jul 28 18:48:37 CEST 2013
Hi Marguerite Su,
> Hi, mates,
>
> I have a wild idea that instead of crying "new ffmpeg breaks my
> package!",
it's a old problem. In the past ffmpeg didn't release new versions for
years. I had to put svn snapshots from time to time and it was always
compilcate. But we had les packages and every package had an maintainer
and active developers.
Inbetween a lot of multimedia programms are no longer developed for
years (yesterday I've visited the xine homepage and followed the links
to all the external projects, it's depressing. The same situation with a
lot of libs needed by other packages...
> we should document/maintain a page or develop a policy about:
>
> How to port some basic functions from ffmpeg 0.7 series -> 1.0 series
> and ffmpeg 1.0 series -> 2.0 series, like avcodec_encode_video ->
> avcodec_encode_video2 or CodecID -> AVCodecID, which are very easy to
> port (you don't have to be a coder at all, Google will help you do
> most of the works if you find a similar patch).
Sounds like a good idea, but I'm not sure if we can handle doing the
upstream work, too.
> Same thing can also apply to gstreamer-0_10 to gstreamer-1_0
>
> Here's the simple reason:
>
> If upstream ffmpeg has been 2.0 now but a package is still using 0.7,
> we can consider it as a drop taget or a dead project.
It's easy, if it is a standalone software, but what's about
libs/programms used by other software?
> Or, we (Packman) is regularly turning to a trash.
That's one of the problems at the moment. I think packman has gone to
big for sparetime roling release without testing branch.
> I took a look at Essentials/Extra/Multimedia, there're so many such
> _junk_ packages
Maybe it's time for a big cleanup. Creating a list of all packages, and
every packager has to mark the packages she/he supports, all packages
without an entry should be removed or mybe deaktivated in PMBS.
> BTW, the openSUSE policy (who breaks it, who fixes it) doesn't work in
> our project, because we're basically amateurs instead of paid
> developers. It's not fair to force a main dependency maintainer
> (ffmpeg/vlc/Mplayer) to fix all the stuff because almost all of our
> packages depend on them.
That's a good point.
> [RFC 2] Package Maintainership
>
> (A) I saw lots of dependencies which have already been in openSUSE.
>
> We created them just to provide package for, eg: SLE_11. Or we created
> them first, then openSUSE have them.
>
> No matter what the reason was, they're not building now.
>
> I think those who introduced them should now be responsible to delete
> them. And our repository maintainers should be _very_ careful about
> introducing such packages in the future (After 6 months, no one will
> know what this package is for).
No objections against this.
> (B) Some packagers maintain a same package on PMBS as OBS, because in
> PMBS, packages can provide extended functions.
>
> But, please make sure such packages on PMBS are _not_ in a _broken_
> state. (Remember: After you did an update on OBS, you just finished
> half of the work!)
>
> Or such packages will be deleted (eg: chromium-ffmpeg/conky and so on)
>
> We got Packman sponsored to provide extended packages, not to provide
> junk/broken packages, we should keep Packman maintained and don't turn
> it to a trash. Personally I don't like to _drop_ any single package,
> because that package is a day of work from a packager like myself.
> But you't can move on if you take too many things on your shoulders.
After Toni, Detlef and Pascal left packman, there are hundreds of
unmaintaned packages, I don't think we can keep them all.
--
Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/
Manfred | http://packman.links2linux.de/
More information about the Packman
mailing list