Re: long-broken packages (some are removal candidates)

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Tue, Apr 03, 2012 at 09:12:41AM +0000, David Holland wrote:
> On Mon, Apr 02, 2012 at 08:06:11PM -0400, Amitai Schlair wrote:
>  > Can someone kindly recapitulate how our pkgsrc lives change if DESTDIR
>  > support becomes mandatory? The costs and benefits been explained
>  > before and I remember on balance finding them compelling.
> 
> It's been the default for a while without the roof of the dungeon
> caving in. The only particularly noticeable problem at this point is
> that if you're doing source builds, ~useless binary packages
> accumulate in /usr/pkgsrc/packages until cleaned out by hand. This is
> more in the way of a hassle than a serious problem though. That and I
> guess builds are somewhat (but not all that much) slower and use more
> transient disk space.

My take is that with the atomic unit being a binary package, we have a
situation where machines are much more easily managed, updated,
manipulated.  An update didn't work properly?  pkg_delete it,
re-install the old one.  Builds from source didn't give you that
ability by default, and it wasn't always easy on the source side of
the house to get this functionality.

It's also much easier to support more advanced ways of managing
packages, such as our binary package managers, and package views,
using binary packages.  Adding signatures to each package is much
easier (and is also very necessary these days).  More on that over the
next few months.

I think that pkgsrc, i.e. the ability to build from source over a huge
number of platforms, is the way to do it. I don't want to rely on a
binary package from someone else, whose options, compilers, subsidiary
libs, build process, and other digital hygiene practises are unknown.
But I also want to be able to manipulate packages easily, especially
on embedded appliances.

As for binary packages overflowing the server - if your build server is
strapped for space, you've got many more problems than binary packages.
 
> On the plus side you can (for most packages anyway) do everything but
> the final binary package install as non-root, plus the time window
> where things are missing during a live update is reduced (though not
> as much as it might be), the PLIST check becomes much more reliable,
> etc.

That's been the case since we brought in just-in-time su, which was in
the 1990s. Please, please, please do not try to download or build as root,
there are too many things that can happen to you.
 
> That and of course the packages listed in the other thread break. Many
> of them are already broken for other reasons anyway. There are only a
> couple that really need to be fixed before such a transition is made.

That's a consequence of using the Debian-like "user-destdir" variation
of a staged install (which is a perfectly acceptable way of doing it,
don't get me wrong).  When we did package views originally, that was
only one way that we had of doing staged installs, we also had special
versions of install(1), pax, cp etc, which recognised the target dir
and fixed up accordingly.  It may be that's an easier option for this
kind of thing.  (where that method fell down was in all of libtool's
shuffling of bits around, all kinds of utilities were invoked on the
various libs.  This isn't a problem for things like ezm3). 
 
> And we need to figure out what to do with cvsup and ezm3. I've already
> stated my opinion.

I'll mention to releng that there may be a pullup coming soon for 6. 
If we can transition people to something a bit more easily manageable
(in a pkgsrc sense) than cvsup, I'll be able to retain some hair. 
Perhaps.

Regards,
Alistair