Request for help: Distro releases and library version table

[Josh Sled]

On Sun, 2005-10-16 at 17:59 +0100, Neil Williams wrote:
> On Sunday 16 October 2005 5:01 pm, Josh Sled wrote:
> > Especially since it's been so long since the last release, we should
> > seek to make the next release one that can work on fielded systems.  As
> > such, it shouldn't depend on libraries that are currently in the
> > unstable/testing/development track of distributions.
> 
> That's a misconception of how Debian works. Of course we target library 
> versions of certain fixed distributions but Debian policy is that all new 
> releases go into unstable (unless experimental is justified) and move through 
> the procedure from there. Unstable itself is a moving target and the package 
> maintainers will take care of the exact versions of the libraries as of that 
> time.

That's fine... we can get the new release into the process for the
future.  But I'm primarily talking about a gnucash release that can be
compiled against existing systems, even if it's not an official package.


> Unfortunately, this makes for difficult work with regard to the libgoffice 
> snapshot which fits one specific libgsf version and not later ones.

Yeah, it does.  Debian doesn't have any "slotting" capability?  There's
no way to have two different versions of a library installed at the same
time?  I can't believe that this hasn't already come up in other
situations.  If nothing else, you can manually install the old versions
in /opt/gnc-deps and point the gnucash build at them.


In any case, it looks like we might be able to depend on
libgoffice-0.1.0 if we include both it and libgsf-1.13.1 in the gnucash
tree.  The combination of their dependencies appear pretty
straightforward and widely-supported.  I was hoping to get this resolved
this weekend, but that email thread took way too much time; lemme
double-check the version numbers and requirements and try to get to it
resolved this week.


> > Certainly when the next Debian stable release is frozen we should have
> > an updated version of gnucash that's using contemporary libraries.  But
> > I'm focused on now, not a year from now, right now.
> 
> Then we release a tarball based on whichever versions we need for the 
> "lowest-common-denominator" with provisions for later versions and the Debian 
> maintainers package it for the latest versions in unstable. That's how Debian 
> works.

Yeah ... that's what I'm talking about: a gnucash release based on
library versions out in the world.  But the "provisions for later
versions" isn't always possible; if there's a non-backwards-compatible
change, then there is.

I want to get to a situation where we don't have to depend on old stuff
because we're having frequent-enough smaller releases that people don't
feel quite so compelled to upgrade when we *do* do a release, but
instead are willing to wait until their distribution naturally upgrades.
But we're really far from that right now, especially with the G1 -> G2
transition.

Or we could just decide to drop the policy and start depending on
whatever we need to to get a release out as quickly as possible.  But
there are downsides to that, too.

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`