Re: [Cpanplus-devel] Advice requested; Automatic building of debian packages from CPAN modules
On Tue, Dec 07, 2004 at 01:58:57PM +0100, Jos I. Boumans wrote:
> >>They can. I believe you want to look at "Replaces".
> >>http://www.debian.org/doc/debian-policy/ch-relationships.html#s-
> >>replaces
> Is it save to 'replace' a file, even if the client installing it
> doesn't have it yet?
Yes. You're just declaring a relationship.
> >So there is nothing preventing someone updating a core module with a
> >new, more recent, version in a separate package.
> Except if their target install dir is "PERL", which i think the rules
> override, but i'm not sure
> -- they set DESTDIR=vendor (schwern?)
Packagers should set INSTALLDIRS=vendor overriding whatever the module
wants to do. That's what vendor is for. Debian does this.
If you haven't already, have a read through the Debian Perl Policy.
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html
> If you look at the failure, you'll see it was actually a script though
> that failed to
> install, and i'm afraid they all go into the same bin dir...
Yeah, executables are the problem. On Debian INSTALLSITEBIN is
/usr/local/bin but INSTALLBIN and INSTALLVENDORBIN both go into /usr/bin.
As a packager you should use the vendor directories so you will have
conflicts. In these cases I think "Replaces" is the way to go.
Similar problem with INSTALLMAN*DIR and INSTALLVENDORMAN*DIR.
I believe simply setting "Replaces: perl-modules, perl-base, perl" in any
CPAN module which has a default INSTALLDIRS of "perl" should do the trick.
perl-modules says it replaces libtest-harness-perl which is ok. It declares
that it conflicts with libtest-harness-perl << 2.40-1 (ie. the version it
contains). I don't think this should cause a problem.
--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
You don't need the bullet when you got the ballot.
-- George Clinton
Reply to: