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 [EMAIL PROTECTED] http://www.pobox.com/~schwern/ You don't need the bullet when you got the ballot. -- George Clinton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
