[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backporting question

On Thu, Nov 20, 2003 at 10:06:53PM +0100, Benedict Verheyen wrote:
> ----- Original Message -----
> From: "Colin Watson" <cjwatson@debian.org>
> To: <debian-user@lists.debian.org>
> Sent: Thursday, November 20, 2003 3:26 PM
> Subject: Re: backporting question
> <snip>
> > Erm, sometimes, but it depends how complicated the dependencies are.
> My
> > subversion backport requires six other packages as well (apache2,
> db4.1,
> > neon, swig1.3, tcl8.4, and tk8.4), some of which are needed at
> run-time
> > and some of which are just needed in order to sort out all the
> > build-dependencies.
> >
> > Backporting is really a development/packaging job, I think, which is
> why
> > it's not particularly documented for users. It probably can't be - it
> > can legitimately be a complicated task. This is why developers who
> > produce backports often make them available for others to use.
> Maybe but a lot of people seem to be wanting to use one app or
> another on stable.
> <snip>
> > I'm not sure what the functional difference is between backporting and
> > installing from CVS. Backporting gives you a set of .debs, but they're
> > built on stable for stable.
> Hhhm. I'm not sure i understand. For exampe: you get unstable source
> on a stable environment but you need unstable libs also. Some of the
> libs are also needed on runtime so you will end up with unstable
> libraries on your system or am i wrong? Why wouldn't you use pinning
> then and just install these packages from unstable or does that
> pull so many other stuff in that the system becomes unstable instead
> of stable?
> > The reason why people backport is generally to avoid having to use
> > *core* libraries from unstable (e.g. libc6), not applications. Simply
> > installing extra applications shouldn't destabilize a Unix system.
> So the fact that stable is called stable and not unstable is because
> of some core libraries and not so much because of the apps?
> Is using the latest version of say libc6 such a bigger risk than using
> the version say from stable? Or am i mixing stability with risks
> here?
> Benedict

Forgive me if I'm wrong, but when there are serious differences between
various versions of a library, it is necessary to use the version of the
library that the application was compiled with.  So a binary install will
cause trouble, but a recompilation from source might very well succeed
when you mix distributions.

Couldn't there be some way of identifying which version of a librar
something was compiled with so that at run time the correct version
can be dynamically selected among a suite of different versions?
Does it really need to be impossible to have several versions of one
library installed on one system?  And if it's not impossible, shouldn't
the package system and the run-time loader be aware of this?

> -- 
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: