Re: perl-base 'conflicts'
On Thu, Dec 23, 2004 at 10:30:26AM +0100, Jos I. Boumans wrote:
>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.
If you like, although I'd suggest the simpler Foo::Bar -> cpan-foo-bar
since the "-perl" suffix is redundant with "cpan-", and I'm a bit
dubious as to the value of the "lib" prefix even for Debian packages
(Perl Policy formalised pre-existing practice on this naming
convention).
>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 =/
Right. Although this occurs with locally installed modules now, and is
something which admins need be aware.
>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?
I tend to think that the gymnastics of avoiding path conflicts under
/usr/bin and /usr/{lib,share}/perl5 make SITE a much more attractive
option. Conflicts as described above (newer version in VENDOR) can be
resolved by the admin manually if required.
Even better than SITE would be /opt, but this would require some more
noodling with @INC (and possibly tweaks to ExtUtils::MakeMaker and
Module::Build to add INSTALLDIRS=opt). Do-able, but wouldn't work until
a new perl package was released with these changes.
Rationale: this is exactly what /opt is for and strictly speaking
packages shouldn't install to /usr/local.
>>As I asked in an earlier message, what is your goal?
[...]
>Not so much 'every package' -- many users of debian use debian because
>of their package manager, and ideally everything they install is a
>package. [...]
I disagree. The "package manager" is just dpkg+apt, which is
intrinsically no better than rpm+apt-rpm/yum/whatever).
What is attractive about Debian is *not* that there are 15000+ packages
convieniently built and bundled, but rather that all those packages
[should] work together. This is the advantage that Debian offers over
things such as rpmfind and freshrpms.
For this reason I'm a tad wary about mechanical processes for creating
packages--the goal for Debian maintainers should always be "better
packages" rather than just "more packages"--doubly so since the process
of creating a Debian package from a Perl module with a reasonable
Makefile.PL or Build.PL is trivial.
Having said that, I can however see that having the additional resource
of the proposed autobuilt cpan-<module> packages may be an attractive
option to users.
Don't get too tied up in the corner cases though, presumably the 80/20
rule you referred to earlier will allow a broader selection of packages
to be available as packages, and leaves the resolution of the subset of
the 20% which may pose a problem on a specific system up to the
discretion of the administrator.
--bod
Reply to: