[clc-devel] Perl versions in footprints
(This was filed in FS #37, but because of the comments, I'm lead to believe that it got rejected for the wrong reasons - so I'm opening it here for discussion, where we're not stuck in a stupid web interface.) Python is nice enough to keep its modules in a <major>.<minor> versioned directory, so footprint mismatches are rare, and when they do occur, it's a pretty good hint that the modules *needs* to be re-tested. However, because Perl puts its modules in a <major>.<minor>.<micro> directory, every upgrade triggers footprint mismatches for all Perl modules, most (all?) of which are bogus. Since we're a source distro, our general upgrade logic is that when a library (or "module") is upgraded, it's a good idea to rebuild dependent packages. Perl (and Python, which doesn't even promise bytecode compatability between micro version upgrades) modules is no exception to this. So, I suggest ignoring the perl version in the footprint like it already happens for kernel modules. Please note that it's the path in the footprint which is ignored, *not* the actual path in the file system. Also note that the purpose is to avoid bogus footprint mismatches in packages with Perl modules, not the perl package itself. This means that when Perl is upgraded, it won't find the modules compiled for the old version (just like it happens now, so our upgrade logic is kept intact.) And as can be witnessed by the attached suggested patch, implemention is trivial. With that said, nobody died from bogus footprint mismatches fo far, so if the proposal is rejected, that's fine - I just want to be sure it happens for the right reasons :)
On Fri, Apr 07, 2006 at 02:16:13PM +0200, Mark Rosenstand wrote:
So, I suggest ignoring the perl version in the footprint like it already happens for kernel modules. Please note that it's the path in the footprint which is ignored, *not* the actual path in the file system. Also note that the purpose is to avoid bogus footprint mismatches in packages with Perl modules, not the perl package itself.
I agree. This already happened with CRUX 2.1 when we had to update perl because of security reasons. Every single port containing something perl-related had to be updated because of the fact that the version is hardcoded in footprints. I don't think I've ever seen a single CPAN module that would be broken by a micro-version update of perl.
This means that when Perl is upgraded, it won't find the modules compiled for the old version (just like it happens now, so our upgrade logic is kept intact.) And as can be witnessed by the attached suggested patch, implemention is trivial.
Yep, looks good to me, makes our lives easier and fits with the KISS principal. I don't see any cons with this, so I give this proposal a +1. // Jukka
Mark Rosenstand [2006-04-07 14:16]:
(This was filed in FS #37, but because of the comments, I'm lead to believe that it got rejected for the wrong reasons - so I'm opening it here for discussion, where we're not stuck in a stupid web interface.)
Aha, funny. -100, see FS #37. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
In FS #37, Tilman Sauerbeck wrote:
I feel this patch violates the KISS concept, it's a tad too much magic for me :/
I think the suggested patch is simple and not very magical, but alternatives are of course welcome. In any case, please try to weight the pros against the cons: + Less maintenance + Fewer bogus mismatches for users + Less noise in our svn history - A simple (but none-the-less additional) expression added to an existing sed proc in pkgmk
Also, if we do it for Perl, we'd have to do it for any other package that uses version information in directories somehow.
Why would we have to do that? It would of course make sense - if that other package had 9819 potential packages (CPAN module count) which installed files in its micro-versioned directory ;-)
"But Perl is in core, $other_package isn't" is a weak excuse :P
Yes, but I haven't used it. To look for bad excuses, please read the mail :-)
Mark Rosenstand [2006-04-07 18:48]:
In FS #37, Tilman Sauerbeck wrote:
I feel this patch violates the KISS concept, it's a tad too much magic for me :/
I think the suggested patch is simple and not very magical, but alternatives are of course welcome.
Patch Perl.
"But Perl is in core, $other_package isn't" is a weak excuse :P
Yes, but I haven't used it. To look for bad excuses, please read the mail :-)
I haven't claimed you used it :-) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hi, On Fri, Apr 07, 2006 at 14:16:13 +0200, Mark Rosenstand wrote:
(This was filed in FS #37, but because of the comments, I'm lead to believe that it got rejected for the wrong reasons - so I'm opening it here for discussion, where we're not stuck in a stupid web interface.)
[...] because Perl puts its modules in a <major>.<minor>.<micro> directory, every upgrade triggers footprint mismatches for all Perl modules, most (all?) of which are bogus. Okay, I don't know perl well enough for me to confirm this. I'm sure however that 5.6 -> 5.8 wasn't compatible.
Since we're a source distro, our general upgrade logic is that when a library (or "module") is upgraded, it's a good idea to rebuild dependent packages. Yes, and for maintainers to test them against new versions
So, I suggest ignoring the perl version in the footprint like it already happens for kernel modules. Please note that it's the path in the footprint which is ignored, *not* the actual path in the file system. Also note that the purpose is to avoid bogus footprint mismatches in packages with Perl modules, not the perl package itself. However, those "bogus missmatches" don't happen if the port was tested (i.e. verified to work) with the current version of perl.
This means that when Perl is upgraded, it won't find the modules compiled for the old version (just like it happens now, so our upgrade logic is kept intact.) However, unlike it is now, noone can tell whether a packager verified a module against the current version of perl, and we can't run a simple grep to check the ports i.e. in a nightly consistency check.
I've mentioned this in the bug report, your patches provides a fix for exactly two cases: a) the packages are up to date, and the user uses an old version of perl b) the user has a current perl, and a packager didn't test his ports against the latest version of perl Both are not bugs in pkgmk, therefore I think the reason why I closed the bug is still valid: "[The] Patch is not fixing a problem of pkgmk but hides an actual issue of a port (not tested against the current version of perl), and potentially encourages maintainers to consider testing against new versions optional ("but the build works fine either way")" That said, I think your post focuses a bit much on your solution, and not the problem you're trying to solve. Assuming that micro-revisions seem to be compatible, I'd consider it the cleanest solution to look into the perl build files to make install to /usr/*/5.8/ instead of adding a work around to pkgmk. Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net
Hi, On Fri, Apr 07, 2006 at 20:37:37 +0200, Johannes Winkelmann wrote: [...]
I've mentioned this in the bug report, your patches provides a fix for or your patch, rather...
That said, I think your post focuses a bit much on your solution, and not the problem you're trying to solve. Assuming that micro-revisions seem to be compatible, I'd consider it the cleanest solution to look into the perl build files to make install to /usr/*/5.8/ instead of adding a work around to pkgmk. Cygwin uses this it seems: http://www.nntp.perl.org/group/perl.perl5.porters/110070
$ tar tvjf perl-5.8.7-5.tar.bz2 |grep site ... 0 2005-12-30 04:04:48 usr/lib/perl5/site_perl/5.8/ ... 0 2005-12-30 04:04:48 usr/lib/perl5/site_perl/5.8/cygwin/ Haven't found a build script yet, though. Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net
Hi, Sorry for the flood. On Fri, Apr 07, 2006 at 20:57:28 +0200, Johannes Winkelmann wrote: [cygwin, perl path]
Haven't found a build script yet, though. The main patch is the following: http://jw.tks6.net/files/crux/major.version.cygwin.sh.patch.txt
Seems easy enough to try IMO. Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net
On Friday 07 April 2006 21:05, Johannes Winkelmann wrote:
The main patch is the following: http://jw.tks6.net/files/crux/major.version.cygwin.sh.patch.txt
Seems easy enough to try IMO.
Indeed! I prefer this solution too, I just considered the other approach more conservative (and hence more likely to get accepted) since it doesn't mess with the actual locations :-) FWIW, I know Arch installs a directory called 'current' and then symlink 5.8.[0-9] to it, and install the modules into the current directory. I don't recall having seen any bug reports about it. (Not that I'm advocating taking that route - it's too ugly, but gives an idea of the compat.)
Hi! Sorry for troubling you all... In my unauthoritative opinion, the problem is much more deep. CRUX has some set of ports, that other ports are very sensible to. At this time, i can talk about three ones: perl, python and openssl. Obviously, gcc and glibc are also of such kind ) Well, while jumping to a 2.2 branch of core/opt, I had a problem with openssl. Each executable, that had been using libssl.so.0.9.7 failed to start and I had to recompile the port with it. Speaking about perl/python, the patch mentioned leads to potential hard to find compatibility problems. I think it's more simple to mark such ports with in special fashion - saying 'this port is special, all dependencies have to be rebuilt'. This does not break a KISS and follows CRUX's manner of optional extensions. And it's not a big problem to recompile a dozen of ports that ARE AVAILABLE in source dir. Furthermore, the port can be marked eventually - with a minor version jump (python), or permanently (perl updates) prt-get could list such ports after update or even automatically rebuild them if requested. Not pretending this to be considered as a solution of course, but would like to hear you opinion anyway :) Originally Mark Rosenstand wrote:
The main patch is the following: http://jw.tks6.net/files/crux/major.version.cygwin.sh.patch.txt
Seems easy enough to try IMO.
-- Oleksiy
Hi Oleksiy, On Sat, Apr 08, 2006 at 00:52:27 +0300, Oleksiy V. Khilkevich wrote:
Hi!
Sorry for troubling you all...
In my unauthoritative opinion, the problem is much more deep. Sometimes even the "deepest" problem has been solved already. You want to have a look at http://jaeger.morpheus.net/linux/crux/files/revdep
HTH, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net
Seems pretty. This could save a bit of time for me last week :) And this throws my idea away! One can write such script for perl modules. And for python. And no patches needed. Originally Johannes Winkelmann wrote:
Sometimes even the "deepest" problem has been solved already. You want to have a look at http://jaeger.morpheus.net/linux/crux/files/revdep -- Oleksiy
Please don't top-post. On Sat, 2006-04-08 at 18:48 +0300, Oleksiy V. Khilkevich wrote:
Originally Johannes Winkelmann wrote:
Sometimes even the "deepest" problem has been solved already. You want to have a look at http://jaeger.morpheus.net/linux/crux/files/revdep
Seems pretty. This could save a bit of time for me last week :)
And this throws my idea away! One can write such script for perl modules. And for python. And no patches needed.
The script handles another type of problem. Given the new dependency rules for opt and core, it _should_ actually not be needed any longer (but in practice it will be for a while, and it will always be nice to have for verifying purposes) since you'll just rebuild dependent packages when a library change soname. Anyway, it's off-topic.
participants (5)
-
Johannes Winkelmann -
Jukka Heino -
Mark Rosenstand -
Oleksiy V. Khilkevich -
Tilman Sauerbeck