On Wed, Dec 31, 2008 at 02:55:40PM -0800, Scott Francis wrote: > On Wed, Dec 31, 2008 at 12:18 PM, Joshua Rodman > <[email protected]> wrote: > [snip] > > >> the ability to (for instance) tar up everything in /usr/local and know > >> for a certainty you have backed up everything package-wise that was > >> not part of the base OS install, allowing you to do a clean reinstall, > >> is useful. > > > > No, it isn't. > > > > Firstly, the base OS install should be made of packages, or you've > > bascially made the entire base OS install one package which fails to > > support the features of other packages. > > the base in a sane OS has no dependency on aftermarket packages;
Who's talking about aftermarket packages? I'm talking about packages which are provided by the the system. > > Secondly, what use it to back up all the stuff relating to user-selected > > packages, if it might depend upon settings made in the base install? > > You've captured a whole set of files that are likely to not work. > > Hooray. > > user-selected packages do not depend upon settings in the base install > - the base is the common denominator of things (IP stack, etc.) that > work with everything and conflict with nothing. At least, this is how > it works on a sane OS where aftermarket packages are not allowed to > infect the kernel. This is obviously impossible. There are a variety of settings like network stack settings, resource counts and other things which will affect the operation of the installed packages. > > Thirdly, with a sane package manager, you can capture the whole list of > > packages that are installed, and all configuration files for those > > packages, obviating the need for your whole tar operation, as well as > > handling things it cannot (as above) handle. > > yes, pkg_* already does this - it's just _cleaner_ to have all > aftermarket package files under the same hierarchy, Again, this myth of packages supplied by the system being aftermarket. Do you purchase your freebsd code from one vendor and your other open source code from another vendor? > (I can roll my own release and push it out, nuking e.g. /usr/bin > without a care, since I know there's nothing living there that isn't > part of the base, which I'm rolling out. Systems that are consistent > and predictable are a BEAUTIFUL thing.) And with sane packages you can update any component independently, including base packages in the same manner as you would with other software, without deleting all files in system directories. Same result, but with a more consistent user story. > > Lastly, I now have /usr/local to store stuff that was actually installed > > by local user control, which is not package managed at all, which is the > > really fragile stuff. > > /opt for that. or whatever. the specific name really doesn't matter; > what matters is that keeping kernel/base segregated from > ports/packages and from non-packaged aftermarket stuff results in a > cleaner, saner, more predictable system. It's better OS design. Funny that all the software I download from the internet thinks it's supposed to install by default into /usr/local. The various BSDs *might* have an argument if the ports installed into /usr/portlocal or /usr/local/ports something, but they install into the longstanding location for custom-built software. Hateful. > if you're running some other BSD, well, this is one of those areas > where there are non-trivial differences between OpenBSD and everybody > else. It's true. I haven't tried OpenBSD since 2006. With a brand new release, it did not manage to support the ethernet controller shipped with millions of units and a working driver in both FreeBSD and NetBSD. The ports didn't break during compilation because it couldn't download any files, so they didn't get a chance. -josh
