Request for help: Distro releases and library version table

[Thomas Bushnell BSG]

Josh Sled <jsled at asynchronous.org> writes:

> Yeah, it's a pretty constrained problem.  Please try to work with me
> here, though.  We need to target the latest-yet-oldest versions we can
> get away with... I'm trying to find a way to make that work across
> multiple distros.  I'm just trying to figure out what those versions are
> so we can know what we're targeting.

Let me explain.  Targeting Debian stable is not the
latest-yet-oldest.  It's just the oldest.

> But, seriously, a question: if some 'libdependent' went from 0.1.0 to a
> non-backwards-compatible 0.2.0, , and the program 'dependency-needer'
> 1.0 didn't have time to upgrade to use 0.2.0... and assuming there were
> other things that used both versions... what would happen in
> debian-unstable?  Would 'dependency-needer' be dropped?  Would the other
> things that started to use '0.2.0' not be allowed in until
> 'dependency-needer' upgraded?  Would the 'libdependent' author be
> encouraged to release a 0.3.0 that could support both?

It depends.  If the library is not backwards compatible, then it has a
new soname.  (Right??!)  So there is no principled reason why
releasing the new causes the old to be dropped.

For individual cases, it's a waste of time: it's much better to target
the latest library.  Explaining the entirety of Debian's release
procedures and policy is not easy, and they are all intertwined.

We have stable, testing, and unstable.  We have procedures for how
packages in unstable migrate into testing, and how testing is
certified and prepared for release as the next stable.  We have
procedures for how packages themselves are maintained.

So let's suppose that libdependent underwent the change you say.  So
long as dependency-needer still declared a dependency on the old
version of libdependent-dev, a newer libdependent-dev would not be
allowed to migrate into testing until the situation was resolved.  One
resolution is to double the libdependent packages, providing both
versions.  Another resolution is to simply delay the introduction of
libdependent into testing.  Another resolution is to drop
dependency-needer from testing.  Which resolution is chosen depends on
the particular case.

In the case of gnucash, which has a bad history of depending on
out-of-date libraries (really, it just seems *insane* to have to be
explaining again why gnucash's use of out-of-date libraries is causing
disastrouos PITA), if it's the only one that needs the out-of-date
library, then I'll be the one doing all the work.  DON'T MAKE ME DO
EXTRA NEEDLESS WORK.

> Great. Then we don't have to worry about what was released then, with
> respect to Debian.  Awesome. :)  [I think it would still be nice if a
> debian-stable end-user were to be able to download and build the source
> on their own, though.]

That's always nice.  It's not the goal, however.  Since aqbanking is
not in Debian stable, you've already missed that boat.

> I think the general release process is sound.  We're trying to release
> something that can be built in multiple environments.  Ideally, someone
> who installed Ubuntu or Slackware or Fedora or Debian or whatever from a
> CD they picked up at an installfest 6 months ago (i.e., spring of this
> year, which wasn't too long ago) could download, build and run
> gnucash-2.  

Not a chance.  But Debian isn't *about* the CD someone picked up.
That's really just not our model in the first place.

> Of course I want to target the future, and have the release
> work in debian-unstable without developers doing anything special.  But
> really I want to get a release out ASAP so we can start to use those
> more recent libraries and features.

A release of the G2 branch?