[Bcc to wxGTK and audacity owners]
DEBUG util.py:250: No Package Found for wxGTK2-devel
Has this rename been announced? To me it came as a surprise. :(
The root.log of a failed build contained this
DEBUG util.py:250: /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory DEBUG util.py:250: error: %post(bash-3.2-33.fc11.i386) scriptlet failed, exit status 127
which made me search in the wrong direction before noticing the message about not finding wxGTK2-devel.
On Wed, Dec 17, 2008 at 09:06:17PM +0100, Michael Schwendt wrote:
Has this rename been announced? To me it came as a surprise. :(
Honestly, first *I've* heard of it. This is because I'm unfortunately ridiculously overloaded with other things right now....
Michael Schwendt píše v St 17. 12. 2008 v 21:06 +0100:
[Bcc to wxGTK and audacity owners]
DEBUG util.py:250: No Package Found for wxGTK2-devel
Has this rename been announced? To me it came as a surprise. :(
The rename must have been done years ago or better the support for GTK 1.x was dropped and only GTK 2 version of wxGTK with the required compatibility Provides was being built since 2006 (FC-4). I was doing a clean-up of the old things in the spec file and repoquery didn't show any problems. But unfortunately I see that I was looking for wxGTK2-devel in Requires in the source rpms, but not for BuildRequires.
The root.log of a failed build contained this
DEBUG util.py:250: /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory DEBUG util.py:250: error: %post(bash-3.2-33.fc11.i386) scriptlet failed, exit status 127
which made me search in the wrong direction before noticing the message about not finding wxGTK2-devel.
Dan
Dan Horák píše v Čt 18. 12. 2008 v 09:07 +0100:
Michael Schwendt píše v St 17. 12. 2008 v 21:06 +0100:
[Bcc to wxGTK and audacity owners]
DEBUG util.py:250: No Package Found for wxGTK2-devel
Has this rename been announced? To me it came as a surprise. :(
The rename must have been done years ago or better the support for GTK 1.x was dropped and only GTK 2 version of wxGTK with the required compatibility Provides was being built since 2006 (FC-4). I was doing a clean-up of the old things in the spec file and repoquery didn't show any problems. But unfortunately I see that I was looking for wxGTK2-devel in Requires in the source rpms, but not for BuildRequires.
I have checked all packages that link with the "base" wxGTK library and no other package is affected, they all use wxGTK-devel.
Dan
Dan Horák wrote:
I have checked all packages that link with the "base" wxGTK library and no other package is affected, they all use wxGTK-devel.
I think we should have some guideline that such versioned Provides should be kept indefinitely and packages should use them where available. You'll have to readd them when there will be a wxGTK 3 anyway!
For example, in KDE SIG we're telling folks to keep using qt4-devel and kdelibs4-devel and we have no plans to drop those virtual Provides.
Kevin Kofler
Kevin Kofler píše v Čt 18. 12. 2008 v 11:52 +0100:
Dan Horák wrote:
I have checked all packages that link with the "base" wxGTK library and no other package is affected, they all use wxGTK-devel.
I think we should have some guideline that such versioned Provides should be kept indefinitely and packages should use them where available. You'll have to readd them when there will be a wxGTK 3 anyway!
wxGTK = wxWidgets (formerly known as wxWindows) build with GTK as the GUI toolkit
Yea, but the "2" was related to GTK 2.x vs. GTK 1.x, so to extend that logic, "3" would mean wxWidgets built against GTK 3.x. It was not related to wxGTK-1.x and wxGTK-2.x
For example, in KDE SIG we're telling folks to keep using qt4-devel and kdelibs4-devel and we have no plans to drop those virtual Provides.
The wxWidgets API should be stable over all GUI toolkits used (GTK, Cocoa, X, MSWin, ...). And there were probably some differences/incompatibilities between wxWidgets build against GTK 1 and wxWidgets built against GTK 2, that lead the audacity developers to require the GTK 2 version.
Dan
On Thu, 18 Dec 2008 12:09:06 +0100, Dan wrote:
For example, in KDE SIG we're telling folks to keep using qt4-devel and kdelibs4-devel and we have no plans to drop those virtual Provides.
The wxWidgets API should be stable over all GUI toolkits used (GTK, Cocoa, X, MSWin, ...). And there were probably some differences/incompatibilities between wxWidgets build against GTK 1 and wxWidgets built against GTK 2, that lead the audacity developers to require the GTK 2 version.
It's the opposite.
The stable release series of Audacity, 1.2.x, is made for the GTK+ 1 version of wxWidgets. The beta releases have closed the gap and are made for and tested with "wxWidgets 2", albeit for quite some time not the very latest. Meanwhile the requirement is wxWidgets 2.8.x.
We used to have wxGTK, wxGTK2, compat-wxGTK, compat-wxGTK2, and compat-wxGTK26, not just because of Audacity.
IMO, there is no need to keep virtual package names forever. If a package gets renamed after years, the BuildRequires in other packages can be adjusted accordingly.
What I'd like to see, however, is that this is done with an announcement and not for old branches. Else we offer source rpms with broken Requires.
Michael Schwendt píše v Čt 18. 12. 2008 v 12:51 +0100:
On Thu, 18 Dec 2008 12:09:06 +0100, Dan wrote:
For example, in KDE SIG we're telling folks to keep using qt4-devel and kdelibs4-devel and we have no plans to drop those virtual Provides.
The wxWidgets API should be stable over all GUI toolkits used (GTK, Cocoa, X, MSWin, ...). And there were probably some differences/incompatibilities between wxWidgets build against GTK 1 and wxWidgets built against GTK 2, that lead the audacity developers to require the GTK 2 version.
It's the opposite.
The stable release series of Audacity, 1.2.x, is made for the GTK+ 1 version of wxWidgets. The beta releases have closed the gap and are made for and tested with "wxWidgets 2", albeit for quite some time not the very latest. Meanwhile the requirement is wxWidgets 2.8.x.
We used to have wxGTK, wxGTK2, compat-wxGTK, compat-wxGTK2, and compat-wxGTK26, not just because of Audacity.
Since F-7 there is only one wxGTK package, if I read the old specs correctly. That corresponds to the release of wxGTK 2.8.0 and the package was (and still is) built with the wxWidgets 2.4 compatibility compile-time option enabled.
IMO, there is no need to keep virtual package names forever. If a package gets renamed after years, the BuildRequires in other packages can be adjusted accordingly.
What I'd like to see, however, is that this is done with an announcement and not for old branches. Else we offer source rpms with broken Requires.
Here was the old stuff dropped only in rawhide 2 weeks ago, the changelog lies (s/Nov/Dec/).
But I agree that an announcement must be sent.
Dan
Le Jeu 18 décembre 2008 11:52, Kevin Kofler a écrit :
I think we should have some guideline that such versioned Provides should be kept indefinitely
IMHO it is perfectly ok to clean up old cruft, or it accumulates and the packages start to be musty.
The question is how and when.
I'd tend to reserve such spring cleanup to rawhide, in the first month of a new cycle, to leave other packagers time to adapt.
Nicolas Mailhot wrote:
IMHO it is perfectly ok to clean up old cruft, or it accumulates and the packages start to be musty.
But versioned Provides are not "old cruft": * They don't accumulate - if Qt is Qt 4, it only Provides: qt4(-devel) and not qt3(-devel), qt2(-devel) or qt1(-devel), that's the whole point of this system. * They will have to be reintroduced when the migration to the next version happens (e.g. Qt 5), so there's no point in removing them (and we don't plan to do it in the case of Qt).
The wxGTK2 case is particular though in that the maintainer doesn't expect another transition period to be needed when the move to GTK+ 3 happens, because wxWidgets is supposed to abstract the difference away (see his reply to my message). Let's see.
Kevin Kofler
On Thursday 18 December 2008, Kevin Kofler wrote:
Dan Horák wrote:
I have checked all packages that link with the "base" wxGTK library and no other package is affected, they all use wxGTK-devel.
I think we should have some guideline that such versioned Provides should be kept indefinitely and packages should use them where available.
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacin... (especially the last 2 paragraphs)
We encourage garbage collecting old cruft, keeping it around indefinitely should be a pretty rare exception for quite specific cases (or at least that's the way I remember it when we worked on it in FPC).
I suppose that a "should add specfile comment if some compatibility are intended to be kept around indefinitely" note should be added in the above doc though, currently it's only a "should" for the common case where stuff is intended to be cleaned up later.
Ville Skyttä wrote:
We encourage garbage collecting old cruft, keeping it around indefinitely should be a pretty rare exception for quite specific cases (or at least that's the way I remember it when we worked on it in FPC).
Once again, a Provides with a version number attached is *not* old cruft, it's both backwards and *forwards* thinking, because another new major version will inevitably happen.
Kevin Kofler
On Friday 19 December 2008, Kevin Kofler wrote:
Ville Skyttä wrote:
We encourage garbage collecting old cruft, keeping it around indefinitely should be a pretty rare exception for quite specific cases (or at least that's the way I remember it when we worked on it in FPC).
Once again, a Provides with a version number attached is *not* old cruft, it's both backwards and *forwards* thinking, because another new major version will inevitably happen.
This thinking sounds even worse - it is not only about preservation cruft in Provides, but it prepares things so that it is usual/expected and easier to ship cruft as several versions of packages, and thus more or less encourages it. I thought we had guidelines how to do compat-* packages properly and some guidelines about their life cycle but it appears I'm wrong or just can't find it now :(
Ville Skyttä wrote:
This thinking sounds even worse - it is not only about preservation cruft in Provides, but it prepares things so that it is usual/expected and easier to ship cruft as several versions of packages, and thus more or less encourages it. I thought we had guidelines how to do compat-* packages properly and some guidelines about their life cycle but it appears I'm wrong or just can't find it now :(
It's just plain impossible to get all the dozens of packages which use a library like qt ported at the same time. Some changes (e.g. Qt 3 -> 4) will invariably take longer than others (e.g. Qt 2 -> 3), but there's just no way a migration like this can happen with no transition period, especially with the current size of the Fedora Package Collection.
Kevin Kofler
On Sun, Dec 21, 2008 at 06:14:48PM +0200, Ville Skyttä wrote:
This thinking sounds even worse - it is not only about preservation cruft in Provides, but it prepares things so that it is usual/expected and easier to ship cruft as several versions of packages, and thus more or less encourages it. I thought we had guidelines how to do compat-* packages properly and some guidelines about their life cycle but it appears I'm wrong or just can't find it now :(
There is http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages but I don't know if it was ratified. Even if it was not ratified FESCo supported the part about vetoing a compat package if the primary maintainer is not ok twice for compat-python for zope.
There was also http://markmail.org/message/lu6votnbktff4peo?q=fedora+compat+packaging+libra... but there is no conclusion as far as I can tell.
I guess that my personal opinion doesn't matter much (especially now that I left fedora), but I think that having packages in fedora link against compat packages should be avoided as much as possible, but compat packages for fedora users should be considered as regular packages (with a need for parallel installation not to disturb main packages). I would favor a policy to have compat packages maintainers be in initial-CC of main package to help triaging bugs that are in fact for the compat package.
In any case there is already some precedent of compat packages still used in fedora and here for a long time, glib and gtk+. Also the kde people keep precedent kdelibs quite a long tie for the benefit of fedora users. Last there is libnet10 which is here since 2003, and found a new maintainer when I orphaned it though nothing in fedora itself links against libnet10.
-- Pat
-
Dan Horák -
Kevin Kofler -
Matthew Miller -
Michael Schwendt -
Nicolas Mailhot -
Patrice Dumas -
Ville Skyttä