Request for help: Distro releases and library version table

[Josh Sled]

On Sun, 2005-10-16 at 12:05 -0700, Thomas Bushnell BSG wrote:
> Josh Sled <jsled at asynchronous.org> writes:
> > 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.
> 
> Are you volunteering to do that work?

No, but I am trying to help other people do that work.


> > 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.
> 
> Good grief.  
> 
> Please, if you want any new gnucash in Debian, then you need to target
> the new libraries.  Targeting old Debian libraries is a *losing
> proposition*.  I don't know how many ways to explain it.

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.


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?


> There are not going to be lots of Debian stable users who suddenly
> want to run this.  Why?  Because I, the Debian maintainer, will tell
> them that gnucash 1.8.10, which is in Debian stable, is the supported
> Debian version.  I will not be building packages to track stable.  I'm
> am busy on the *next* thing, not the *last* thing.

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.]


> But if you produce something that cannot be built in Debian unstable,
> then I'm just going to ignore it, and the result is that almost no
> Debian users will use it.
> 
> Debian is *not* organized the way other distributions are, and you
> don't seem to understand that.

Now I have a better understanding of how Debian works; thanks for laying
it out for me.


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.  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.

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