On Sun, Oct 03, 1999 at 10:02:55PM -0400, Damir J. Naden wrote:
> Hi Mark Brown; unless Mutt is confused, you wrote:
> > That idea is intented to be closer to unstable than stable - at this
> > point, there would probably be as much hassle updating to the in-between
> > release as there is updating to Potato. Not that there's much hassle
> > with Potato right now.
> if I feel bored over the weekend; what packages and in which order do I
> need to update to get the system to potato- with dpkg command line _not_
> the apt tool? I'd guess libc6 2.1, bash, ldso, libreadline2g and so on
> and so forth. (any volunteeres for a quick how-to? :-) )
That sounds like the sort of thing that a machine is much better at than
me. The quickest way to generate such a list would probably be to do an
apt --dry-run. :-)
> Now, I want new wmaker (assuming there is a package): I do dpkg --i
> wmaker* and two or three other small packages, and I'm off to the races.
> Since it is a bug-fix release, I don't think anything will break. If it
> does, I pull out old packages, do dpkg --i thingy, and I'm safe. An hour
> work, at the very worst.
What happens if a package really does depend on a new library version,
or the package maintainer did a lot of work adding support for some
infrastructure which is only in unstable? At what point would you be
happy with something that depended upon something that wasn't in stable?
> > The stable GNOME packages are actually produced by the Debian
> > maintainers - they're just distributed from the GNOME site.
> So, why would they not be introduced into slink-proposed-updates?
The only things in proposed-updates should be minimal fixes for very
important (eg, security) bugs - things that will go into a new point
release of slink. New upstream releases don't generally make those
criteria, and the GNOME one certainly doesn't.
> > To explain it a bit more clearly: glibc 2.0 is binary compatible with
> > glibc 2.1. If programs break when linked against 2.1 then that is a bug
> > in the program (typically trying to use internal features).
> With all due respect, from my standpoint it doesn't matter where the bug
> is. The fact the program may not run does matter.
It at least tells you where to file the bug report.
--
Mark Brown mailto:broonie@tardis.ed.ac.uk (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFS http://www.eusa.ed.ac.uk/societies/filmsoc/
Attachment:
pgpO3DYT1HpPQ.pgp
Description: PGP signature