Packaging systems [Was: Importing tmux into base]

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Thu, 10 Feb 2011 19:09:45 +0000
David Holland <dholland-tech%netbsd.org@localhost> wrote:

> Postfix has to be in base because base needs to have mail. We could
> conceivably replace postfix in base with something simpler, but
> someone would have to write it and that's so far not been worth
> anyone's time.
> 
> bind should be kicked out; there's no reason other than historical
> tradition to have it in base, and it's a maintenance hassle both for
> us and for sysadmins.

I had to switch to using the sendmail package when sendmail was dropped
from base; which I don't find simpler to use, although that's still
allright. I also use in-base bind and I like that it's real easy to
have a quick chroot setup with it.  Hopefully that if it's removed from
base, the package will be as easy to setup...


It's not clear to me how other serious NetBSD users deal with the
following problem, and would gladly note down suggestions to eventually
try.

As I'm not satisfied with the default build options of a number of
packages, and because of the advantage of signed sources and custom
compiler flags other than custom build options (and some packages can't
be redistributed in binary form, even), I use a dedicated host to
regularily rebuild the software I need from base and pkgsrc using stable
branches.  Other boxes then use pkg_add and al from that custom binary
repository.  So I consider pkgsrc a good tool for custom repository
creation/distribution, just like build.sh is a good tool fo custom base
system creation/distribution.  To minimize VCS issues, cvsup is used to
provide a local mirror of the NetBSD base and pkgsrc trees.

If a security or stability fix happens on a package, more often than
not it happens on -current pkgsrc and by then a number of dependencies
might also have been upgraded on that in-flux branch CVS the currently
used stable branch.  This means that the tree must again be rebuilt on
the build host, and other systems must again update to the various
packages.  Since I rely a lot on stable pkgsrc branches to be able to
easily eventually add a wanted package to the build-list with minimal
hassle, this usually means that I must import myself the updated
package stub in my existing tree to minimize dependency rebuild/update
issues.

On the other hand, if a security fix happens on the base system, I can
easily check the CVS diffs logs to assess the change at a common
location, a build host also regularily builds a stable branch, and
interestingly, the other systems can more easily be updated using the
build.sh install target and postinstall on that pre-built tree than
doing package upgrades.

If other users face this same situation regularily, I'm sure that
unfortunately they also share my impressions that: 1) unless pkgsrc
improvements were made (and it's still unclear to me what exactly would
solve my package-related maintenance problems), syspkg doesn't sound
like an ideal solution, as even more stuff would be exported as
packages; 2) Essencial server/router software are most easily dealt
with when part of the base system.  To me this includes things like:
SSH/MTA/DNS/NTP/FTP/HTTP servers.  Admitedly for HTTP I don't use the
base-system one as I need more complex setups with language
dependencies, and I use my own FTPd where necessary.


Here I'll post about my experience with Debian-like systems, as some
mentionned it on this thread:

There are indeed other systems which take a minimalistic approach to
every package, building them with the minimal options and providing
some options as other packages, which support signed binary packages
and more easily allow to upgrade dependencies on an existing system.
Their base system is minimal and itself consists of packages.
One such example is Debian.

I can say that my experience with it over the years has not been
better, because other problems were common enough: occasional break of
package system software or of the state of existing packages made
because of package maintainer errors, inability to easily update if
the frequency of previous updates was not high enough; need to
custom-build some software because it wasn't built with the needed
options, or built against unwanted dependencies; package system often
interfering with custom built kernels, custom configurations and
permissions.

Because updates must be done frequently enough for them not
to wreck havok at a future update, one is tempted to lazily setup a
nightly update script.  Then suddenly a restore of the packages and its
database from a backup or the package cache is necessary because of
automatic breakage...
And from a security standpoint, automatic updates are not ideal either,
one still has to review patches applied to debian source stubs; a
package could be automatically updated and introduce a new
vulnerability or instability; the binary repository maintainers have to
be fully trusted; etc.


Just to say that no system is perfect.  But so far I still enjoy NetBSD
as it has been very dependable for my uses.  That doesn't mean it's
always hassle-free, of course, but no system I used ever was.
-- 
Matt