[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OpenPackages comments
Wilfredo Sanchez wrote:
> On Tuesday, September 12, 2000, at 09:59 AM, Paul Richards wrote:
> > With it's current usage I think creating a new location, other than
> > /usr/local is a good idea, so that /usr/local goes back to being an area
> > that is outside the scope of the OS.
> > The issue of sharing packages across machines is a trickier one. If
> > we're going to come up with a new directory layout then perhaps it
> > should be
> > /pkg/export
> > /pkg/local
> > to differentiate between files that are host specific and those that can
> > be shared.
> > Although, if the base system and packages become synonymouse then
> > packages can just install into the same directory structure as the base
> > system since everything including the base OS is just another package
> > and can be managed like any other package.
> I still see a need to distinguish between packages that are provided
> by, say FreeBSD proper, and packages that are "other". The former would
> go into the base tree, and the rest into /usr/local and /usr/export (or
> whatever). /usr/local seems fine for non-OS packages.
I think I agree a bit, though I'm not sure :-)
Making some assumptions, which aren't currently the case...
If "official" packages installed into the base directories then there
are two other cases that need to be considered.
Packages that are supplied by third parties.
Code that isn't packaged by anyone.
The latter should go in /usr/local since it's a local sysadmin issue.
What about the former though? Should the package system just treat
packages as the same regardless of who they are supplied by or should it
treat "official" and "non-official" packages differently?
I think I'd prefer a package to be a package, regardless of who created
it. Even if a local sysadmin created a personal package. it should still
be part of the package system and install into the usual place, rather
than being treated differently because it isn't an officially
It doesn't really matter if a home grown package intermingles with a
project supplied package if the package system keeps tracks of files
To unsubscribe: send mail to <firstname.lastname@example.org>
with "unsubscribe bsdports" in the body of the message