[cc to debian-perl added] On Wed, Dec 22, 2004 at 03:31:51PM +0100, Jos I. Boumans wrote: >On Dec 22, 2004, at 3:24 PM, Brendan O'Dea wrote: >>It's in the conflict list for perl-base: >> >> libscalar-list-utils-perl (<< 1:1.13-1) >Some intermediate perl-base's (5.8.4-3 and -4 iirc) even conflicted >with /all/ >of scalar-util.. hence the problem which i pasted in my previous mail.
Nope, not to my recollection. But the epoch would certainly cause your problem. >I'm thinking that if it's 'always' data-dumper, scalar-util and >autoconf, they >could be explicitly excluded, but that's of course less ideal... data-dumper is a special case, an *ancient* package which was added as an unconditional conflict. autoconf is a versioned conflict which was added due to problems with that package not working with a newer version of perl. It was necessary to add the conflict since there was no other way to force the older version to be upgraded (users don't always upgrade all packages to the latest version--selectively upgrading just perl and not autoconf in this case would break autoconf). >>I would strongly suggest that you consider simply creating a new >>namespace for automatically built packages, and using INSTALLDIRS=site >>. >Hmm, the whole idea was actually that this would 'seemelessly' integrate >with the current debian mirrors (and thus using whatever was already >supplied >by the standard debian pool when possible) > >Is there a use-case for this already? Seamless integration is not going to happen in a completely automated way. Sorry. Debian packages are more than just the equivalent of shoving a tarball of the results of "make install" into a .deb. The reason that we have package maintainers is because the process of packaging a large set of disparate software into a coherent whole [distribution] requires both elements of discrimination of communication with other maintainers such that all this mess of packages works together. Moreover that discrimination includes deciding whether or not something SHOULD be packaged. CPAN is a wonderful resource, but you can't possibly tell me that ALL of it is useful. For my own purposes, I'll only package a module if it is either * a dependency of another package I'm building, or * is generally useful Another useful rule-of-thumb for packagers, not specific to perl modules is * if you don't use it, don't package it the corollary of which is obviously, * if you no longer use it, orphan the package. >>Since everything would be under /usr/local, there would be no issue >>with >>replacing files in /usr/bin, or conflicts with Debian packages. >Yes, but would require a dependant module to possibly installed twice -- >once by standard debian tools, once by the cpanplus/debian tool (or more >accurately, namespace). That means we couldn't use what debian has already >provided, which is especially bad if the modules debian provides do debian >specific things or required manual tweaking. As I asked in an earlier message, what is your goal? If it is to provide a template for simplify the process of creating packages for upload to the main archive, then the direction you're currently heading is fine--presumably the maintainer is sufficiently clued to deal with the occasional corner-cases (such as epochs, replacing CORE scripts in /usr/bin, etc). If it is to provide a binary package for each and every CPAN module, then I would stand by my suggestion above: choose a disjoint namespace and install to /usr/local. There may well be some overlap b/w some cases of cpan-foo and lib-foo-perl, but that's not terribly important so long as cpan-* is self-consistent (a couple of redundant Debian packages is hardly a huge overhead). If you intend to tackle both tasks, then perhaps you need to provide a switch to choose the appropriate behaviour. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
