Re: backporting question
On Thu, Nov 20, 2003 at 02:59:11PM +0100, Benedict Verheyen wrote:
> 1. Am i correct that you can backport an app (not all of course)
> by getting the source from unstable or testing and then
> compiling and installing it?
> I don't know the exact instructions to accomplish this.
> Would this work:
> apt-get build-dep <package>
> apt-get source <package>
> dpkg-buildpackage -rfakeroot -uc -b
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
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.
> 2. If a latest and greatest application A uses libs B and C, and
> application A uses functions which are only available in these latest
> libs B and C, you will have to have these installed in order to run,
> right? So you end up with a few unstable libs on your system anyway?
> Wouldn't it be better instead of backporting to install woody and use
> the lastest packages that you want from cvs?
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.
> Otherwise, backporting doesn't seem to make sense: you are using the
> latest software on a stable environment but because you install these
> latest apps, your environment becomes more unstable. Or am i missing
> something (probably)
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.
Colin Watson [firstname.lastname@example.org]