On Wed, Dec 31, 2008 at 12:18 PM, Joshua Rodman
<jrod...@hate.spamportal.net> 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;
that's why it's called "base". While kernel, userland and
ports/packages should all be in sync, it's certainly not a requirement
(and upgrading independently is common and simple - upgrade kernel
first, then userland, then ports tree. Piece of cake, especially if
you're using binary packages, which we all should be.)
> 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.
> 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, for system mgmt
sake (rolling out an upgrade to OpenBSD-XX? 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.)
> 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.
>> If you haven't looked at the non-trivial improvements made in the past
>> few years following the complete rewrite of pkg_*, you are proceeding
>> on false assumptions.
>
> I have never used a ports system that didn't throw compilation errors
> during installs of *packages*. This includes last month.
if you're compiling anything that's already available as a binary
package, you're doing it wrong. if not: is this OpenBSD? did you drop
a line to the package maintainer? The last time I ran into something
that threw compilation errors from a "cd /usr/ports/section/app &&
make && sudo make install" was 5 years ago, and I use OpenBSD on a
daily basis on desktop, laptop and server.
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.
--
Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527
Less and less is done
until non-action is achieved
when nothing is done, nothing is left undone.
-- the Tao of Sysadmin
