Re: perl-base 'conflicts'
On Dec 22, 2004, at 5:00 PM, Brendan O'Dea wrote:
[cc to debian-perl added]
[...]
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.
True, but oddly enough, in an 80/20 situation it works :)
Now, getting back to the scalar-util/data-dumper conflict, we were
thinking of solving it as follows:
* create a seperate namespace as you suggested. Debian style would be
'libfoo-perl' for the module Foo. Ours would be 'cpan-libfoo-perl';
familiar to the debian user and effective when apt-cache searching.
* Add the dependencies not just as 'libbar-perl (>= VER)', but as
follows:
Depends: libbar-perl (>= VER) | cpan-libbar-perl (>= VER)
So it will pick the debian provided package if it is installed or
available, or fall back to the automatically generated cpan package
if it is not. This minimizes the use of auto-generated packages to
just
those that are not provided by debian already, and will neatly avoid
our scalar-util/data-dumper conflict.
* Add a 'Provides: libfoo-perl' line to the now virtual package, so we
can avoid having 2 packages installed at the same time.
* Install our packages into the SITE dir (as CPAN.pm/CPANPLUS.pm
normally
would anyway), to avoid ownership conflicts with other debian provided
packages.
The only drawback i can see here is the following:
At some point, there's cpan-libfoo-perl v1, and a user installs it.
Later, libbar-perl requires 'libfoo-perl v1' (which is provided by
cpan-libfoo-perl) and installs it. Later still, libzot-perl requires
libfoo-perl v2 which is now available (but there's no cpan-libfoo-perl
v2 for whatever reason).
The installer will now 'probably' do the right thing by grabbing
libfoo-perl v2
and installing it as per usual to satisfy the depenendancy. Except,
debian packages install into the VENDOR dir, which is searched only
/after/ the SITE
dir. Effectively leaving Foo v1 to be loaded still =/
Granted, this is a bit of an edge case, but it is the only drawback i
can see right now. We could have our cpan-foo* packages also install in
VENDOR instead
of SITE to avoid this conflict, but that might lead to ownership
conflicts instead. Any suggestions here?
[...]
As I asked in an earlier message, what is your goal?
'yes' :)
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).
That's one part of it -- debian lags behind often in versions (and also
in amount of packages offered, but that's another debate). With the
techniques we have now,
it's become a lot easier to automatically do the 'grunt' work of
generating packages. That should make it easier for package maintainers
to keep up to date with cpan releases and we'd certainly like to help
them make it so.
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).
Not so much 'every package' -- many users of debian use debian because
of their package manager, and ideally everything they install is a
package. dh-make-perl already set the precedent for CPAN modules,
CPANPLUS just does it a little bit better ;) So we'd like to offer
users the option, via a simple plugin, to install a perl module 'via'
dpkg. In addition to that, we'd like to offer a mirror where the most
common (i386) binary packages already live -- autogenerated from CPAN
when they are updated.
If you intend to tackle both tasks, then perhaps you need to provide a
switch to choose the appropriate behaviour.
The 'switch' will indeed be present -- the option to prefix with a
certain string, defaulting to 'cpan-'. Package maintainers can disable
that prefix and
get the 'standard' debian behaviour.. normal users and our own
generated archive
would use the 'cpan-' prefix and thus avoid conflicts, but still have
the luxury of installing via dpkg.
Any thoughts or comments on the subject are of course welcome
--
Jos Boumans
'Real programmers use "cat > a.out"'
CPANPLUS http://cpanplus.sf.net
Reply to: