On Sun, 2005-10-16 at 12:05 -0700, Thomas Bushnell BSG wrote: > Josh Sled <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel