Re: Version requirements for dependancies

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 11 Nov 2008 17:52:11 +0100
    From:        Quentin Garnier <cube%cubidou.net@localhost>
    Message-ID:  <20081111165211.GL366%shaak.vert-toit.net@localhost>

  | I might have disagreed with some stuff in your mail but I've tried
  | reading it to the end twice, and woke up with my neck in a painful angle
  | the two times.

Yeah, sorry about that, sometimes I get carried away.

  | To sum up, I think your point is that no package in pkgsrc properly
  | describe the versions it needs from its dependency.

I wouldn't say that, I haven't looked at every package to know.  What I
would say is that the default model that pkgsrc developers use much of the
time does the wrong thing, and that binary package dependency info is
almost completely broken.

  | This is true, but
  | then it is completely impossible to have that.  Sure, a package can
  | "know" to some extent what past versions of a package it can work with,
  | but there is no way it can accurately know about future versions.

Of course.   You might have missed it while dozing through my message,
but I know about that (it is after all not very startling information.)
I'm suggesting that packages should specify which version(s) they're known
to work with, then the dependency indicates whenever a new version has any
incompatible changes, which pkgsrc then uses to warn users (packages being
compiled) where the upper package is known to work on the older version
but not necessarily with the new one.

  | The points you're missing, I think, are first that it is not exactly
  | what we need to make pkgsrc works better.  Close, but not quite.

Fine, I'm certainly not mandating (as if I could) anything, the better it
all ends up the better.

  | The second point is that this issue shows up in partial upgrades, which are
  | hard to get right, and as a matter of fact I think only pkgsrc (and
  | maybe FreeBSD's and OpenBSD's ports to some extent) try to do that.

That might be true of package management systems, but they're a relatively
new invention.   Before they existed, people used to download and install
things for themselves, more or less randomly, as they needed new applications
or updates.   I can assure you that attempting to make everything use some
consistent versioning, or to upgrade everything just to get a newer version
of one application would never have crossed anyone's mind.   Way too much work.
With pkgsrc (etc) the human effort is much reduced, but it can still be
a mamoth process to do what was intended to be a small update.

  | Binary package systems only have to care about ABI, and this is much
  | easier to do with only binaries given a proper update tool.

There are advantages and disadvantages to each.
 
  | What pkgsrc lacks at this point, is build information embedded in
  | binary packages (or rather, installed packages, which is essentially the
  | same).

Yes.

  |  When you update or build from the pkgsrc tree a package that
  | depends on another package already installed, it should use information
  | embedded in the installed pacakge to build.  But that is also very hard
  | to do.

Yes, I think I said that solving the binary package problem was not
a trivial exercise.

  | That said, I'd rather see pkgsrc developers work more on providing a
  | better experience for binary packages users (or, as I am sure some would
  | say, *an* experience in the first place) than making partial upgrades
  | work better.

It's important to remember that there are two different classes of
binary package users, and we need to handle both.   First are the ones
I think you're mostly considering, which are the people who download
(or would) binary pacages from ftp.netbsd.org (or ftp.pkgsrc.org or
anything else like that) - kind of the way that (some) linux systems
use apt_get and similar (but in a way that actually works without tons
of end user work).

The second class are people like me - people who build and then use their
own binary packages.   I like to build (and keep relatively up to date)
binary packages for everything in pkgsrc that I think it even remotely
possible that I might want to use some day - I don't do bulk builds, as
that builds way too much for me (at the most I attempt to build less than
half of what pkgsrc contains - with both what I pick explicitly, and all
the dependencies they need.)   You may have noticed that I send build-fail
type PRs about all kinds of odd packages - but very rarely a "doesn't work"
PR.   The latter is because I almost never run any of them, I only upgrade
the (much much much) smaller set I install when absolutely necessary, and
then I want to upgrade the minimum I can get away with - and in some cases
much less often than perhaps I should, but mostly because many upgrades
insist on upgrading way too much (partly because of the pkgsrc src level
dependency issues - things get linked against new libraries for no better
reason than that the new library exists).

I'd like to see both (src and binary) work better ... I think we need to fix
the problems we have with binary packages (and I agree, it isn't simple) first,
as I suspect that the src problems are currently features when it comes to
binary packages - without the "bugs"/"features" binary packages wouldn't work
even as well as they now do.

  | Not that it stops me from ranting about the latter every
  | now and then, because short of having a binary package repository, and
  | not willing to update packages all the time, partial upgrades are still
  | what works best.

Agreed.

  | Hey, reader, wake up!  No, don't complain, subscription to this list
  | doesn't come with a masseuse.

Nah - you're still way behind my missive, you'll have to try harder ...

kre