Re: using packages in slink
On Tue 15 Sep 1998, tony mancill wrote:
> carrying slink and updated my package list. Now dselect wants me to
> update about 80MB of software on my system. This is ok, I guess, but I
> happened to notice that one of the packages was libstdc++ 2.9. If I load
> this and then build my package (wanpipe, which has one executable which
> links against this), isn't that basically forcing everyone who wants to
> use wanpipe to start using slink instead of stable?
Yes, but that's not to be avoided, as you can't put a new upload into
the stable distribution (unless it contains a fix for a serious
(security) problem. "Stable" doesn't refer to the quality, but to the
state of the packages (i.e. you can assume that in the "stable"
distribution the package versions won't change). Of course, a package
upload may cause the distribution te become unusable, but that seldomly
happens (and is accompanied by loud and plentyful complaining on the
lists, and always fixed the next day).
> On a related note, I'm still completely in the dark about how packages
> migrate through the different sub-distributions within a release. i.e.
> should everything I upload to master be classified as "unstable"? And
> when/how/by which criteria will it move to "slink" and then maybe to
"Slink" is the codename for the next official release of Debian, and
thus is currently the "unstable" distribution. If you look closely,
"unstable" is a symlink to "slink", just as "stable" is a symlink to
Once "slink" has been frozen and fully tested and approved, it can be
released. At that point, the "stable" symlink will be changed to point
to "slink" instead of "hamm", and a new unstable directory will be
created (with whatever codename someone comes up with at that point).
So, the packages don't move, the entire distribution is relabeled.
> that I'm maintaining a package, I want to be using the latest revision,
As you should...
> but don't see a way of doing that outside of placing that package in my
> dists/stable/local directory on my company's internal mirror. I'd also
This conclusion I don't follow...
> like to understand better what makes up a (point) release and how we can
A point release contains the security updates I mentioned. Usually not
> help those who are working on it. (i.e. upload revs early and often, or
> try to keep uploads to a minimum while the package slowly ripens in my own
> test environment...)
Upload often. That way it will be tested by many more people, who will
find bugs you will never encounter. So, expect bug reports, and handle
them gracefully. The people reporting them are doing you a favour!
BTW, a lot of this is also the the "developers reference", which is a
package, or follow the "developers' corner" link on www.debian.org.
home: email@example.com | work: firstname.lastname@example.org | debian: email@example.com
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands