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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
