On Thu, Jun 30, 2005 at 03:20:03PM -0400, Greg A. Woods wrote:
> [ On Wednesday, June 22, 2005 at 21:01:32 (-0400), Sean Davis wrote: ]
> > Subject: make update == make broken
> >
> > I don't hear these kinds of complaints from FreeBSD users regarding
> > portupgrade.
> 
> I do.  Maybe they don't complain online, but they sure as heck do in
> person.
> 
> Fundamentally though what you and they are both complaining about is
> that you don't like paying the cost of properly rebuilding all
> dependencies, and what that really boils down to is that either software
> has become far too complex and inter-dependent for you to independently
> maintain it, or else these systems (pkgsrc, ports, etc.) are all
> creating too many interdependencies.
>
> As you know it really is mostly due to DLL hell.  Welcome to the world
> of modern applications software.  All your base are belong to us.

Yes... and I don't think this will ever stop being a problem until NetBSD
starts offering up-to-date binary packages, which I don't see happening
for -current.

> I avoid the vast majority of unnecessary interdependencies by static
> linking everything that can possibly be static-linked, and also by
> avoiding many of the big ugly interdependent messes in the first place.
> Not everyone wants to do such things though.  E.g. you seem to want KDE
> badly enough that you're quite upset when you're forced to delete it
> because it's inter-dependent on something else you need to upgrade, and
> then you're left without it when it fails to build again.

when I'm forced to delete it? I think "when pkgsrc deletes it behind my
back when I tried to update a totally unrelated package" would be more
accurate.

> Unfortunately even static linking doesn't eliminate some of the biggest
> pains to rebuild -- it seems the bigger a package, the more likely it is
> to require dynamic loading, usually for some horribly silly reason.
> 
> Sadly given the state of libtool (and the fact we're all forced to use
> libtool) it's almost impossible to static-link some libraries into some
> dynamic-linked applications but not into others and vice versa (i.e. if
> you build .so's, libtool will use them despite your best attempts to
> prevent it).  This means even more, unncessary, interdpendencies
> (repeated builds and total avoidance of pre-built libraries from other
> packages, which is basically half-way to what the chroot'ed builds do
> already though).
> 
> Ultimately I think the solution for these kinds of complaints is to stop
> building your own software from source on production machines.
> 
> That means either only using binary packages someone else has
> built.....
> 
> Which is what some of the GNU/Linux crowd have done, and you really
> don't hear so many of these kinds of complaints from the majority of
> those that have -- they just re-install everything that needs upgrading
> all at once (which is _much_ faster and nearly infinitely more reliable
> than de-installing it all, rebuilding it all and then installing it all
> again);
> 
> Or....
> 
> Use a separate machine to do the builds on.
> 
> It really is best to always and only use binary packages on production
> machines.  That still leaves you with the decision of whether or not
> you're going to independently dedicate the resources needed to build
> your own binaries, or whether you're just going to buy the CDs and thus
> pay someone else to do it for you.

I would be quite happy to use a seperate machine to do the builds on. Would
you like to pay for it? no? me neither. I don't make enough that I can buy
another computer just to build packages on.

-Sean