On Thu, 2006-05-18 at 19:56 +0200, Thomas Vander Stichele wrote: *snip* > DirectFB will cause this > problem for extras for every release they ever make. So it is different > from everything else in Fedora Extras that can be upgraded easily for > every new release. > *snip* > If that is a consideration, > basically that means that we should never accept any update in Extras > that breaks ABI/so name/compatibility. > > That would be a fine rule, but afaik we don't have it yet. I don't know > if I would be for or against; but if it was a rule, I'd probably stop > packaging directfb because it would become pointless to have it in > extras at all. Given that this will always happen with Directfb - third party repositories that do not want to break should plan ahead and provide a compat package so that when directfb is updated, they can provide the needed shared libraries themselves. It should be the 3rd parties responsibility to keep compatible, at least in this case since it is known that updates change the library version. > > > No, I allow for the possibility of me having made a mistake :) > Here's what I did. I ran: > repoquery --alldeps --whatrequires directfb > > That gave me evas and ecore, as well as xine and mplayer. > > For evas and ecore, I checked the last %changelog author, as well as the > owners.list file, and mailed ivazquez. > For xine and mplayer, I contacted anvil. That seems sufficient to me personally. > > I'm going to reiterate that the "potential security issue" is something > that IMO should really be fixed in the package manager. I think it's > wrong to blame individual package maintainers for creating a potential > security problem that is left there to be abused by the package manager > of choice. The reasons I've heard for this IMO do not weigh up against > the problem that *any* repository can create this way. There is no security issue IMHO. If yum breaks because of a third party repo or rpm is installed, that is the users responsibility to take of since they are using unsupported packages. *snip* > > If it's going to remain blocked for reasons mentioned above, that's fine > as well, but then I'm better off dropping the package from Extras, since > that would mean Extras is not the place to have this package. If > effectively directfb can't be upgraded, there's no point in shipping it > from Extras. I hope it can stay in Extras. As far as a policy - coordination of rebuilding the packages that need to be rebuilt so that they get pushed in same yum push is sufficient IMHO. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
