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

Re: Incoming: directfb soname problems

> > We don't have many packages like directfb afaik that chose to have a
> > different so name for each release.
> That's not really relevant.

It's the heart of the discussion we're having.  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.

> > when I asked on IRC, people felt it was enough
> > to warn the affected maintainers.  Which is what I did.
> I strongly disagree with that.  The fundamental problem is that one
> can't possibly reach the whole target audience.

It seems you're suggesting that since I can't know who's using directfb
outside of extras, I can't reach them.  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.

>   Have the maintainers
> ack'd that they will be able to ship updated packages shortly (or at
> all) after your update hits the repos, for all affected distro versions?

I sent a mail to ivazquez (evas packages) and anvil (xine and mplayer),
and to hans de goede (because he's interested in directfb).  I did not
get any feedback from ivazquez or hans, an anvil told me he would
rebuild livna packages when the directfb update would hit extras.

Yes, I agree with you that ivazquez should give his OK.

> Are you sure you mailed the correct individuals?

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.

>   Rhetorical: If not,
> have all end users been notified what they need to do in the meantime?

I don't know how to contact all end users.

> If the answer to any of these is "no", this is a potential security
> issue, which you're essentially willingly inflicting on users.

You caught me - I was hoping to set up a new bot net after my old one
got found out :)

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.

> I didn't see immediate commits following the directfb one to affected FE
> packages in the commits list, which already proves that as implemented,
> this update was a failure even within FE.

It sounds like you're saying that in practice everyone affected by the
change should be making their commits at the exact same time ? That's
doable for this package I guess, since it's only two people if you agree
that only extras should be taken into account.

> A real policy in FESCO's TODO list.  Some members were skeptical whether
> a policy is needed, but this reoccurring example probably serves as a
> good case in point.


I think this is being blown out of proportion.

In extras, there are two packages affected.  Both packages are part of
the same functionality - getting Enlightenment stuff running.  They've
been in extras for three months.  I doubt there is a wide installed base
of people that have *both* directfb and enlightenment running, but I
could be wrong.  Anvil was willing to update his livna packages as soon
as the update came out (FWIW, there is no good way of coordinating
updates between extras and livna except for poking anvil.  So there will
always be a window in which the typical user's yum setup is temporarily
"broken".)  Am I missing something ?

> I've temporarily moved the packages out of the needsign queue so the
> update can be reconsidered (as a whole or partially), and if still
> wanted, properly communicated before done.

Well, I doubt you will have a lot of people asking for directfb on this
list.  There is a lot of stuff being packaged in extras, and not every
user is on this list.  DirectFB is a niche project.  But for what it's
worth, here's my request to put it back, and I will communicate the
update to whoever you think I should communicate it to.

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.


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