> > 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. <snip> 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. Thomas -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
