dean@huxley.org (Dean Huxley) writes:

>Christoph Badura <bad@ora.de> wrote:
>> In general it is not a good idea for packages to find and depend on random
>> crap installed on a system.

>In a way, I could take this same argument and say USE_PERL5 is doing that 
>right now. ;-)

Right.  I call that a bug.  Anyone mind if I fix that?  I.e. in the USE_PERL5
case:

DEPENDS+= ${LOCALBASE}/bin/perl-5.00404:...

>> You're probably better of making yourself an updated perl pkg and hack
>> bsd.pkg.mk to use/depend on that instead of the supplied perl.

>So anyone who wants to run the latest version of perl should do this?

Yes.  Although, I wouldn't mind a perl-current pkg and a change to
bsd.pkg.mk so that one can set the perl version in /etc/mk.conf.
Although, we'd have to be careful to not get such an "infected" binary
pkg on the FTP site.

>If they already have it installed without using the package system
>they'll have to reinstall with a their own package so things show up
>with pkg_info.  Then they have to modify bsd.pkg.mk and remember not
>to overwrite it the next time they get pkgsrc.tar.gz, but then they
>might have to merge in changes.  

Right.

>Of course, if they don't know to do all this, the default behaviour
>of a pkg with USE_PERL5=yes is to overwrite the version of perl
>already installed on the system, even if it is newer than the pkg'd
>one.

Excuse me?  How is the "version of perl already installed on the system"
overwritten by the pkg version?  Have you set LOCALBASE to /usr/local?
Don't do that if you don't want to have random crap in LOCALBASE
overwritten by the package system.  That is one reason why LOCALBASE
is /usr/pkg by default.

We've had enough problems with pkgs picking up random crap from the
system.  Including binary pkgs on the FTP server which used programs
outside of the "managed area".  With over 700 packages that we have to
support it is just not practical to make them work with random crap
installed on the system.  It is far easier to hack the packages to rely
only on the stuff in the base OS and the software managed through the
package system.  A side effect of that is, that is fairly easy to
reproduce the exact software configuration on another machine.  That's
a big plus in production enviroments.

Actually, I think that bsd.pkg.mk should reset the PATH so that
only the system directories and the "managed areas" are listed in it.

>I don't see this as an desirable solution...

Well, do you have a better solution?

-- 
Christoph Badura					www.netbsd.org

	Anything that can be done in O(N) can be done in O(N^2).
	-- Ralf Schuettau (after looking at a particular piece of code)