[packman] [RFC] Main Dependency Portability was: Re: ffmpeg update to version 2.0
pascal.bleser at gmail.com
Sun Jul 28 17:48:06 CEST 2013
On Sun, Jul 28, 2013 at 3:36 PM, Marguerite Su <i at marguerite.su> wrote:
> Hi, mates,
> 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.
Yes, but it's not that easy to find out that a package is dead.
Or maybe there are some new OBS tools I don't know of.
> Or, we (Packman) is regularly turning to a trash.
Yes, we have had that problem over and over.
> I took a look at Essentials/Extra/Multimedia, there're so many such
> _junk_ packages
> 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.
Right, and also, we are still very low on contributors compared to the
amount of work we have.
It is and remains the key issue IMHO, as well as an almost complete lack of
coordination (or, say, "team"), but that has always been an issue.
We do have a list, we do talk, but often things/changes/ideas/decisions are
simply not discussed on the list in the first place.
And I have been guilty of that as much as everyone else, so it's no blaming
or fingerpointing, just an observation which I believe is correct.
(Please prove me wrong :-))
> [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.
Yep. And that's a major issue as well, as people who take our packages and
put them on build.o.o, or do the same package as we provide on build.o.o,
plain simply don't talk to us about it. There's a web UI, there's a
mailing-list, people could quite easily check whether the package exists on
our build service instance and contact us to find the package and see whom
should maintain it where.
Most of us have a few key packages that we'd like to keep maintaining,
because they're our "babies", because we've put a lot of work in them for
many years, and/or also we have a lot of expertise maintaining them (e.g.
MPlayer, gstreamer, and most notably ffmpeg come to mind).
But still, given the amount of work and given the little time we all have,
I don't believe that any of us would be obnoxious about keeping a package
into Packman at all costs and having to do the work ourselves.
It's just that people don't also check in our OBS instance (or our
repository -- pretty much everyone uses Packman in their list of repos, a
simple "zypper se" would already find most of them) to see whether it's
there or not, and just poke a mail on our list (don't even need to
Again, I'm not fingerpointing or whining here, but the situation is and has
been like that for a very long time.
It is something we need to approach and solve as well, amongst a few other
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).
Yeah, that's tricky, OBS doesn't have a way to have.. say.. "comments"
about packages where we could explain why it was introduced.
Arguably, there is the package description which we might abuse for that,
and in some cases, we actually do.
There is another aspect too: we did have some volatility in terms of
packagers over the years, and a few highly productive packagers have left
(e.g. oc2pus and Detlef, who have been maintaining hundreds of packages,
literally). I, myself, have been off the radar for quite a while too.
So yeah, it's a small group of people doing a large amount of work, and
when one person leaves, for one reason or another, it is quite a massive
issue in many ways, including what you mention above: why is that package
there in the first place? can I just drop it?
> (B) Some packagers maintain a same package on PMBS as OBS, because in
> PMBS, packages can provide extended functions.
Or, also, someone packages something that was on Packman on OBS (e.g. in
multimedia:libs or multimedia:apps), doesn't tell us anything about it, we
find out a while later, and we're the ones to adapt our package to link to
that one and add extended features.
(yes, that is *quite* a bit annoying...)
> 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!)
That happens too, a lot. When we do poke people who maintain a package in,
say, multimedia:libs or :apps, and tell them that we link + extend it on
Packman, they usually do not get an account on the Packman OBS in order to
see whether the changes they make to the upstream package breaks in Packman
or not (heck, they could even check using the Web UI).
> 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.
Since when is Packman sponsored? Well, it has been, a bit, in return and as
a thank you for the work we have been putting into this for so many years
(remember, it even predates openSUSE), but no one can really say that we
are sponsored to do this and that and, in return, we should do this and
I agree that we do have a lot of baggage in our repositories, but cleaning
it up is work too, and finding out whether a package may be dropped or not
is not a piece of information OBS gives us easily -- there, again, unless
I'm wrong, maybe I just missed the tools to get that information.
In any case, thanks for kicking off the discussion :-)
More information about the Packman