[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Incoming: directfb soname problems



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]