Re: [current] Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert wrote:
> ... but /usr/pkg supplanting /usr/local is one of the things that I
> like about NetBSD.
/usr/pkg sounds a little bit odd ... ( at least for my ears).
Why not choose what Solaris uses (/opt) ?
It would be an advantage, when designing filesystem size of your OS,
that now you would have two completely separate paths /usr and /opt.
Installing ports in /usr means, having a too large /usr or to mount
a new filsystem under /usr (/usr/local). Mounting an fs under a mounted
fs I dislike much ...
What about the following installation hierarchy
/opt/category/port/{bin,etc,include,lib,libexec,man,sbin,...}
with symlinks to
/opt/{bin,etc,include,lib,libexec,man,sbin,...}
This would be an advantage for larger packages, as now you can very
easily see, what belongs to a package and what not.
Additionally you can install multiple versions of a port at the
same time, and slowly migrate the configs/settings to the new port.
For critical server application this scheme gives you more fine grained
control, concerning what version to use and you can easily go back if
you need...
pkg_version -c is cool, but it simply overwrites your working port,
keeps the configs, but pray, that everything runs.
The above suggested symlinks are a needed evil, so that you again only
need one place for manpages and binaries...
It gives you a lot more directories and symlinks, but when installing
it on a different filesystem, I think you can very easily live with
it, concerning the better control over installed packages.
Another plus is, that you now see _directly_, what files, config-files,
etc belong to a software, that is huge and complex ...
packages like KDE wouldn't f*up /usr/local as they do now.
Teaching KDE to install in /usr/local/kde is complex and I lost
fun doing so when I frist tried a year ago...
Andreas ///
--
Andreas Klemm Powered by FreeBSD SMP
Songs from our band >>64Bits<
Re: [current] Re: Confusing error messages from shell image activation
Michael C . Wu <[EMAIL PROTECTED]> types:
> I know I should not jump into this bikeshed. But IMHO, whereever
> we have our packages install to, we should also place
> our ports metadata (/var/db/pkg) and the ports skeleton in the
> same place, preferably a mountpoint. This allow me to switch
> between different sets of installation with ease. (No, please
> do not tell me to change PREFIX and mv /usr/local /usr/local.bak)
> With this setup, I can rm -rf , and
> have a clean system again. For the ports developers, we can
> switch between configurations without the need for chroots or
> jails taking up disk space.
Ok, I can see wanting that. And I can see how it would be handy for
ports developers. But my instant reaction was "yuch". The reason for
that is that, unlike the contents of ${PREFIX}, the contents of the
ports metadata is *not* generally recreatable from the /usr/ports
tree. This means it's more precious, and you might want to back it up
more frequently, etc.
While some method for ports developers to move the metadata (say an
environment variable) should be provided, I think the above is a good
reason for leaving the default as is.
BTW, pkg_add (at least) honors the environment variable PKG_DBDIR to
set the location of the ports metadata directory. Is there some reason
you can't just set that to /usr/local/etc/db/pkg or some such?
Final comment - I wish more ports developers *would* set PREFIX.
Re: [current] Re: Confusing error messages from shell image activation
On Mon, 11 Dec 2000, Michael C . Wu wrote: >I know I should not jump into this bikeshed. But IMHO, whereever >we have our packages install to, we should also place >our ports metadata (/var/db/pkg) and the ports skeleton in the >same place, preferably a mountpoint. This allow me to switch >between different sets of installation with ease. (No, please >do not tell me to change PREFIX and mv /usr/local /usr/local.bak) >With this setup, I can rm -rf , and >have a clean system again. For the ports developers, we can >switch between configurations without the need for chroots or >jails taking up disk space. I would agree strongly with this. Something like: /usr/ pkg/ bin/ db/ <-- /var/db/pkg, why is that in /var anyway? it's not exactly temporary or transient information. etc/ include/ info/ lib/ libexec/ man/ sbin/ share/ src/ <-- /usr/ports/* This would make it easy for one to return his system to a pristine state. Simply removing /usr/pkg would get rid of all third-party information. It makes sense to package this entire directory together. If one wanted a fresh system he could remove /usr/pkg, do a make world, and tell mtree to remove anything not in the system mtree file. -- Brandon D. Valentine <[EMAIL PROTECTED]> "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert scribbled: | For foreign or not-so-foreign packages and software, I've seen | /usr/local, /local, /usr/contrib, /opt and /usr/pkg. One site that I | worked at was even pedantic that /usr/contrib was for externally | generated software and /usr/local was for software written and/or | maintained locally. I've also worked in environments where different | directory structures implied the level that the IS guys intended to | support the software. I know I should not jump into this bikeshed. But IMHO, whereever we have our packages install to, we should also place our ports metadata (/var/db/pkg) and the ports skeleton in the same place, preferably a mountpoint. This allow me to switch between different sets of installation with ease. (No, please do not tell me to change PREFIX and mv /usr/local /usr/local.bak) With this setup, I can rm -rf , and have a clean system again. For the ports developers, we can switch between configurations without the need for chroots or jails taking up disk space. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
