Re: perl-base 'conflicts'
[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
Reply to: