Re: question for sources.list
On Sat, Sep 03, 2005 at 10:11:04PM +0200, David Jardine wrote:
> On Fri, Sep 02, 2005 at 10:40:40PM -0600, Paul E Condon wrote:
> > On Sat, Sep 03, 2005 at 12:09:39AM +0200, David Jardine wrote:
> >
> > > Paul, I think you were one of those (forgive me if I'm wrong) who
> > > shot me down a couple of months ago for suggesting that such words
> > > as "stable", "testing" and "unstable" might better be reserved as
> > > purely descriptive words for real things like "sarge" or "etch".
> >
> > I don't think I shot you down. In my opinion, release code names ought
> > to be the primary key by which a release is designated.
> >
>
> Sorry for the misdirected accusation. It can't have been you.
>
> > [...]
> > So, until some time in the far future, people should not say to
> > newbies that release code names and release status names ('stable',
> > 'testing', etc.) are interchangeable. They are not. Existing support
> > for release code names is, in fact, quite restricted by comparison.
>
> I haven't talked about "interchangeability" but I have recommended
> using release code names instead of release status names (thanks for
> clarifying the terminology :)) in "/etc/apt/sources.list". I see
> now that this can cause trouble if they extend the logic to the
> "preferences" thing. I'll just shut up in future (as I always say).
>
> Incidentally, I've noticed that the manpage for "sources.list" only
> talks in terms of release status names. Is there a cut-and-dried
> answer to all this? In debian policy, perhaps?
>
>From my limited investigation it appears that release code names are
implemented using hard links in the package repositories. But the
implementation is not clean and simple. The links point to files
whose names are variations on stable, testing and unstable and the
contents of these files contain references to the currently
valid code name assignments. This is a level of obfuscation that I
had not expected to find.
'release status names' sounds like a useful addition to apt-get
terminology. If it were folded into the official docs they would
be a lot more understandable.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: