On Sat, Aug 26, 2000 at 01:23:19AM +1000, Drake Diedrich wrote:
> On Fri, Aug 25, 2000 at 09:09:44PM +1000, Anthony Towns wrote:
> > On Wed, Aug 23, 2000 at 06:42:39PM +1000, Drake Diedrich wrote:
> > >> * separate pools for each component (main, contrib, and non-free,
> > >> and presumably non-US/main, non-US/contrib, and non-US/non-free
> > >> also)
> > > The design I was working on would have these all as separate archives
> > > consulting a common database.
> > I don't really understand what you mean by this. Can you give a sample
> > layout? What do you mean by "archive"?
> Most archives are in different nations: Debian-US, Debian-non-US.
That doesn't tell me what you mean by "archive". Do you consider contrib
and non-free to be separate archives as well?
[I wrote]
> > Similarly, I don't really see what you mean by "different paths", or
> > why different archives might need to be on different machines, or what
> > you mean by sharing the pool, or why any of this requires different
> > incoming directories...
[In response to:]
> > > Constraints can be (and currently are)
> > > applied to ensure that there are no conflicting overlaps between archives
> > > (same path, different checksum).
> paths refered to the full path within the filesystem of each archive.
Then two different files never actually have
the same path. Either because they'd be the same file
(debian/dists/woody/main/binary-i386/foo/bar_1.2-3_i386.deb), or because
separate archives are called, eg, debian-non-us/dists or woody/non-US/main
or similar.
> > > [...] pool/main and pool/non-free could both be in the same
> > > directory though, they'd just need separate incoming directories to feed
> > > them.
> We will likely always need master servers in different countries for
> legal and bandwidth reasons, so I've designed the pool database to
> record that information (the archive), and to prevent those archives from
> overlapping files that are not identical.
But we *don't* need separate servers or separate incoming directories
for main and non-free right now. Not legally and not technically.
> pinstall doesn't consult the .changes files for source files, just the
> .dsc.
Then that's broken...
> The only additional interesting information in the .changes file
> is the Section: Getting at the .changes file before uploading the .dsc to
> the pool is messy.
...and something in there's poorly designed.
> > A license interpretation change means the package should *not*
> > be in the component it was previously in, not that it should
> > suddenly be in two components. Dual free/non-free sources aren't
> > reasonable. Non-distributable things can't be packaged.
(xacc and xacc-smotif is an existing example of a free source producing
a non-free binary)
> > > CREATE TABLE pool (
> > > distribution INT4 NOT NULL REFERENCES distribution,
> > > deb INT4 NOT NULL REFERENCES deb,
> > > arch INT4 NOT NULL REFERENCES arch,
> > > section TEXT,
> > > install TIMESTAMP
> > > );
> This was in response to a requirement that there be a table listing these
> things. I quoted the table. The NOT NULL REFERENCES implies that each of
> the integers is the primary key of another table, and insists that that
> entry in the second table cannot be deleted unless the entry in the pool
> table is deleted first. It also demonstrated that the section field
> can be stored in the pool table, and therfore overridden differently in each
> distribution. section is up for grabs by the release managers, the pool
> doesn't use it for anything at present.
Unfortunately it doesn't tell me what a "distribution" is (is it "woody"?
is it "woody/non-free"? is it "woody/non-US/non-free"?), it doesn't tell
me what a "deb" is, it doesn't tell me how "deb" and "arch" interact,
or what happens for binary-only-recompiles or arch: all packages. It
doesn't give me any context for anything.
I mean, yes, it's a translation of my ASCII relational notation into SQL,
but it doesn't actually *tell* me anything.
> > Huh? It's trivial to work out which component each .deb is in right
> > now: you just look at its path, or the path of the Packages files that
> > reference it.
> The problem isn't old .debs, it's new .dscs. They're loaded in first.
And new uploads have a .changes file which tells you what you want
to know.
> Maintaining the signature is required in order to recreate the database
> in the even of a flush, and it's a good idea anyway to keep mirrors honest
> and security-paranoid happy.
ObVious: so don't flush the database.
Alternately, structure the pool layout so you can still work out the
component based on the filename.
Adding the Section to a .dsc or ignoring components altogether doesn't
increase security in any measurable way, either.
> There was more in this than you read. The packagepool doesn't use any
> symlinks.
The only reason symlinks are particularly useful are either to support
old programs and partial mirrors, or to make it easy so people browsing
the ftp site don't have to look in a myriad of places for things.
> After it takes over generation of the Packages files they could
> all be removed. Eventually was also long term, until stable distributions
> are deleted entirely from the master ftp server and moved to a different
> location. flag day didn't refer to a day when everything changed, it
> refered to the day they finish changing. The other proposals I've seen for
> package pools require moving all .debs into the pool/ directory and putting
> them in hashes, while keeping everything running using symlinks. Under this
> packagepool they never have to move at all. They can be moved, but they can
> also just sit where they are forever. Moving them costs mirrors whether it
> happens in one day or 300.
Moving them happens anyway, when, eg, slink gets moved from ftp-master
to archive.debian.org (or potato, or woody, or whatever).
In the long term, moving .debs into a separate directory from the pool
is useful simply because it means we *don't* have to keep moving them
around every release.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgph4YfMOFrCE.pgp
Description: PGP signature