On Fri, Jun 1, 2012 at 5:24 AM, Steffen Schwigon <s...@renormalist.net> wrote: > Marvin Humphrey <mar...@rectangular.com> writes: >> On Wed, May 30, 2012 at 7:40 AM, David Golden <xda...@gmail.com> wrote: >> >>>> I really wish that versions and dependencies were expressed at the distro >>>> level rather than the module/package level. Allowing multiple version >>>> numbers >>>> within an atomic unit of installation doesn't make sense. >>> >>> I agree. Now all we need is a DeLorean, a flux capacitor and 1.21 >>> gigawatts. >> >> *chuckle* >> >> It's possible to overlay a package management system on top of >> Perl5/CPAN which uses distro-level dependency specification. I don't >> know the gory details, but isn't that what apt-get, rpm, etc do? > > It is. And it *only* is about the details. And gory. And the "who". Not > the band nor the Dr. but the "who will do and maintain it". So we are > back to David Golden's proposal involving 1.21 gigawatt. :-)
It appears that during the 1990s and early 2000s, Perl module developers had less of an appreciation than we do today for the problems caused by implicit exports. Fast forward to the present, and common practice has evolved -- few new modules uploaded to CPAN pollute namespaces by default. For backwards compatibility reasons, most of the problematic modules (e.g. POSIX) cannot be changed. Yet we have still found ways to benefit from the hard-won experiences of those module authors and their users. I hope that future users may benefit from the experiences of authors like Phillip on the subject of distro-vs-package/module-level versioning. That starts with us developing a thorough understanding of the problem, and perhaps developing consensus around best practice. In that vein, I would like to know: do you, as someone who has spent time in the trenches working with packaging, believe that version numbers and dependencies are best expressed at the distro level or at the package/module level? It seems to me that the primary benefit to expressing versioning at the package/module level is that because CPAN.pm only reads versions embedded in actual source files, it can never fall out of sync -- as opposed to packaging systems which maintain an external registry that can have incomplete data when an alternative installation mechanism has been used. Some might argue that it is also beneficial to be able to express dependencies in terms of individual modules rather than distros, but the problem there is that you may not want an implicit upgrade of the *other* modules within the distro. (FWIW, I'm currently collaborating with a couple other people on a system which has some versioning and packaging functionality -- it's not for Perl modules per se, but the lessons of CPAN are relevant and this thread has been useful. Neverthless, I'm also interested in this topic strictly as a CPAN author. It would have been nice if the Lucy community could have avoided the time-consuming troubleshooting we had to go through.) Marvin Humphrey
