Re: Bug#54985: debian-policy: handling of shared libraries
[Please followup these thoughts to deity@lists, not to -policy]
I wonder if apt-get could perhaps be enhanced to allow something like:
apt-get --compile --dist=unstable foo
Then you download just the unstable source and compile it locally.
Would that be of help? apt.sources would have to allow lines
somwthing like:
deb http://ftp.debian.org/debian stable main
deb-src http://ftp.debian.org/debian stable main
dist=unstable deb-src http://ftp.debian.org/debian unstable main
and would ignore lines preceeded with dist=xxx unless specifically
asked for on the command line. Could even imagine something like:
default-dist=stable
dist=stable deb http://ftp.debian.org/debian stable main
dist=stable deb-src http://ftp.debian.org/debian stable main
dist=unstable deb-src http://ftp.debian.org/debian unstable main
I wonder how feasible that would be? And as Build-Depends: fields are
(correctly) added to an increasing number of packages, apt-get source
should be able to use them, too. (It may do so already, I don't
know.)
I wonder also whether this model can be extended, and allow for
something which someone asked me, namely that one could install or
upgrade to an individual package from unstable (and any dependencies):
apt-get --dist=unstable install foo
and then subsequent apt-get dist-upgrade's would note that this
package should track unstable. There would have to be a way of
returning the package back to the frozen or stable track, perhaps:
# just one package, stop following unstable:
apt-get --track=default foo
# all unstable packages now track frozen
apt-get --track=frozen --dist=unstable
I don't know whether this is feasible to implement.
Julian
On Thu, Jan 13, 2000 at 10:16:03PM +0000, Ian Jackson wrote:
> Roland Rosenfeld writes ("Bug#54985: debian-policy: handling of shared libraries"):
> > The normal situation is, that users have both packages libfoo and
> > libfoo-dev up to date, which means, that they are the same version and
> > then both packages include the identical file.
>
> Perhaps you run only systems which are up to date with unstable.
> However, my experience is quite different. There are costs associated
> with continuously upgrading, especially from unstable: constant
> change, risk of bugs which take time to diagnose and/or fix,
> difficulty of obtaining binary packages in a timely and cost-effective
> way, &c. For this reason I like to run most of my production systems
> using the current stable release.
>
> However, sometimes I'm hit by a killer bug, or want to upgrade a
> particular package to the latest and greatest version. Often it's a
> while before I can update to the latest stable, and in the meantime a
> security fix comes out, so I need to install a package from the new
> stable when my system is still mainly from the previous release.
>
> However, with the current arrangement I can't do that. Whenever I
> want to upgrade a binary package I have to update the libraries that
> it depends on to at least as recent a version. But, because the
> runtime libraries and development libraries must be in version
> lockstep, this means I have to upgrade the development package too.
> Then, due to further dependencies, I usually find I have to upgrade my
> entire development environment, and often including the C and C++
> compilers and a whole slew of unrelated tools, to the version from
> unstable.
>
> Furthermore, once I have done this on one system it becomes incapable
> of building binaries which run on systems I haven't done it to.
>
> This whole thing is just too brittle. What is needed is to decouple
> something. The most obvious point to decouple is at the division
> between runtime and development shared libraries, because there is
> already an interface there - the library ABI - which has usually been
> carefully worked out by the library authors to be reasonably stable
> and forward-compatible. Furthermore, this is a very simple and easy
> change.
>
> (A corresponding change to dpkg-shlibdeps will probably also be
> required to get the runtime dependencies right on each rebuild.)
>
> As far as I can tell its only disadvantage is that the archive will
> grow by a small amount, and that a small amount of extra disk space
> will be used on machines used for development. The extra disk space
> used by another copy of the .so file is actually very small compared
> to the space used by debugging, static and profiling libraries, of
> which nearly all development systems will need at least some.
>
> Ian.
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Reply to: