perl and python footprint mismatch errors
Hi I experienced something weird and seems nobody reported it (or I didn't hear of it). Well, there are some ports dependent on 'python' and 'perl', which have errors after merging into opt/2.5. For the 2.5 release, perl has changed from 5.8.8 to 5.10.0, and python from 2.5 to 2.6, and (for what I know ) this version number is hardcoded in footprints[1] (also in some dependent ports). So, some maintainers should pay attention before merge their commits into the 2.5 branch. Some affected ports and their maintainers: (opt) (perl ports) $ for port in $(grep 'site_perl/5.8' -r * | cut -d'/' -f1 | uniq); do echo -ne "$port "; grep Maintainer $port/Pkgfile; done git # Maintainer: Tilman Sauerbeck, tilman at crux dot nu imagemagick # Maintainer: Simone Rota, sip at crux dot nu mod_perl # Maintainer: Juergen Daubert, juergen dot daubert at t-online dot de p5-html-parser # Maintainer: Lucas Hazel, lucas at die dot net dot au p5-html-tagset # Maintainer: Lucas Hazel, lucas at die dot net dot au p5-uri # Maintainer: Lucas Hazel, lucas at die dot net dot au (python ports) $ for port in $(grep 'python2.5' -r * | cut -d'/' -f1 | uniq); do echo -ne "$port "; grep Maintainer $port/Pkgfile; done dbus-python # Maintainer: Lucas Hazel, lucas at die dot net dot au iotop # Maintainer: Johannes Winkelmann, jw at smts dot ch libxml2-python # Maintainer: Juergen Daubert, juergen dot daubert at t-online dot de mysql-python # Maintainer: Juergen Daubert, juergen dot daubert at t-online dot de pycairo # Maintainer: Simone Rota, sip at crux dot nu pygobject # Maintainer: Simone Rota, sip at varlock dot com pygtk # Maintainer: Simone Rota, sip at crux dot nu pypanel # Maintainer: Johannes Winkelmann, jw at tks6 dot net pyrex # Maintainer: Lucas Hazel, lucas at die dot net dot au python-xlib # Maintainer: Johannes Winkelmann, jw at smts dot ch rdiff-backup # Maintainer: Simon Gloßner, viper at hometux dot de [1] I would to propose you a pkgmk hack similar to that we have for kernel modules ports, all we need is the current installed version for perl and python. See kernel footprint hack for take an idea: http://crux.nu/gitweb/?p=tools/pkgutils.git;a=blob;f=pkgmk.in ... make_footprint() { pkginfo --footprint $TARGET | \ <http://crux.nu/gitweb/?p=tools/pkgutils.git;a=blob;f=pkgmk.in;h=1cc40d60d274cb3a31e7896f3ad3ce4e2864673c;hb=HEAD#l198> sed "s|\tlib/modules/`uname -r`/|\tlib/modules/<kernel-version>/|g" | \ sort -k 3 } ... Thanks, Jose V Beneyto
Hi
I experienced something weird and seems nobody reported it (or I didn't hear of it). Well, so far we've only asked to test the ISO, not necessarily the
Hi, On Mon, Oct 27, 2008 at 7:10 PM, Jose V Beneyto <sepen@users.sourceforge.net> wrote: ports, so it's somewhat to be expected that ports don't work on 2.5 for one reason or the other (python/per footprints may be one thing, gcc 4.3 build errors another). Once the ISO is relatively stable (and I'm pretty sure it is) we should go ahead and ask all maintainers to start porting their software (perl/python is one thing, gcc 4.3 another). At the same time, development of 2.4 should be frozen, such that all efforts are geared towards getting the new release ready.
[1] I would to propose you a pkgmk hack similar to that we have for kernel modules ports, all we need is the current installed version for perl and python. Not sure if that's really justified, given that we usually don't do major updates of perl or python inbetween releases. In addition, such a hack would also invite people not to update their perl/python ports, which would most certainly cause problems down the line if they install dependent ports which require an up to date perl/python.
Cheers, Johannes -- Johannes Winkelmann jw@smts.ch
On Mon, Oct 27, 2008 at 07:10:26PM +0100, Jose V Beneyto wrote:
Hi
Hello Jose,
I experienced something weird and seems nobody reported it (or I didn't hear of it).
Well, there are some ports dependent on 'python' and 'perl', which have errors after merging into opt/2.5. For the 2.5 release, perl has changed from 5.8.8 to 5.10.0, and python from 2.5 to 2.6, and (for what I know ) this version number is hardcoded in footprints[1] (also in some dependent ports). So, some maintainers should pay attention before merge their commits into the 2.5 branch.
Some affected ports and their maintainers: (opt)
[...] Thanks for the report, I'm pretty sure the maintainers will look at their ports soon. This has to be done for every major new release of perl, python and ruby, to name only the interpreters that came to my mind. Basically it's the same with libraries, like e.g. db or mysql-client, at least the depending ports have to be rebuild. [...]
[1] I would to propose you a pkgmk hack similar to that we have for kernel modules ports, all we need is the current installed version for perl and python.
Well, the situation with kernel modules is quite different: - We do not provide a kernel port, thus its out of maintainers' control which kernel version the user is using. - As a consequence he cannot garantee that the module works with every kernel version! - The module must precise fit the kernel version, not easy nowadays where we have a new kernel version very often. So the hack for kernel modules seems to be appropriate and necessary, but shouldn't be applied to other stuff, IMHO. Thanks and best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
participants (3)
-
Johannes Winkelmann -
Jose V Beneyto -
Juergen Daubert