Re: a question about apt_preferences,

[Paul E Condon <pecondon@mesanetworks.net>]

On Mon, Jun 27, 2005 at 03:43:55PM -0700, Todd A. Jacobs wrote:
> On Sun, Jun 12, 2005 at 03:47:16PM -0600, Paul E Condon wrote:
> 
> >I am attempting to set up apt_preferences to pin priorities on
> >the basis of the name of a release rather than on the basis of
> >(stable|testing|unstable). I tried a line :
> 
> >Pin: release a=etch
> 
> I filed a bug report against apt for this recently (although the 
> mechanism I was using was slightly different), and the maintainer 
> basically said "Yeah, and the problem is...?"
> 
> So, your choices are to:
> 
>    1. File it as a bug report. Maybe if enough people complain, it will 
>       cease to be a "feature."
> 
>    2. Avoid using the code-names, which of course may cause problems or 
>       require manual intervention whenever testing goes stable.
> 
> Either way, good luck!
> 

Although, I'm not a Debian developer, I do have some understanding of
database issues and database design. Because of this reminder of my
complaint, I started looking into the database that supports apt. I
found that the files for various distributions are placed in
directories that are named with the code name of the release to which
they belong, and the words 'testing', 'stable', 'unstable' where used
for links to those directories. So, in a sense, the code name is the
primary key and the stable/testing/unstable (STU) designation is an
alternate key. This comports well with the idea that when sarge was
released, the only thing that had to be changed in the repository to
effect the change was to change a few soft-links. But thats not the
whole story.  Essentially all the files contain hard coded, internal
references to the STU designation. So the real transition for sarge
from testing to stable involved a lot of rewriting of control files.
And, furthermore, essentially all the files also contain hard coded
references to the codename of the release. This is un-normalized
database. It is well known that un-normalized database is considered
harmful.  Much of the difficulty in explaining apt to people who are
new to Debian is caused by this flawed design. If you are going to
have persistent objects (releases) in a repository, you really must
have a persistent key value for each of them.

I believe the repository design should be changed to eliminate this
design flaw. For any release, the codename is the unique identifier
that stays with the release through its whole design life from initial
nameing to eventual transfer to the archive of old, inactive releases.
No file that is part of the control information of the release should
refer to the release by anything except its designated codename. 

Because the current design is so muddled on this issue, it will not
be easy to arrive at a new design that solves this problem and that
can be introduced smoothly and easily.  But I hope for better.

-- 
Paul E Condon           
pecondon@mesanetworks.net