Re: RFC: implementation of package pools
On Thu, 19 Oct 2000, Eray Ozkural wrote:
> This thing again. :(
>
> I agree with Adam, splitting into directories according to a prefix
> of the name is _nonsense_. By the way, this topic had been discussed
> before and my sober proposal was silently dismissed. [1]
>
> Let's review this matter.
>
> * Ideally, all packages would lie flat in a single directory. example
> /package-pool
Agreed.
> * However, some people suggested that putting all packages for
> a single source is a good idea (it becomes a distribution point for
> that software). I totally disagree with this. But let's say it's
> done that way. (It doesn't matter for the following argument...)
Harder for humans to navigate(yes, people still manually look at the archive).
I would suggest that binary-<arch> and binary-<all> hash on the name of the
deb(but multi-level), and source hash on the src pkg name. Encoding the
source of a package, by using a directory name, is duplication of info, as the
info is in the headers of the package(which exist in both the .deb, and the
index(Packages)).
> * This means that all packages or package directories would be in a
> single directory. Unfortunately this is not possible because ext2fs
> is a terrible filesystem. [can't handle dirs with a lot of entries well]
Most definately.
> * You have to split the pools directory in order to preserve
> file-system performance for a large number of packages. That is,
> _performance_ is the only reason for doing this. The directory
> names ultimately don't have to be human readable, since such _simple minded_
> prefixing doesn't at all ease browsing the ftp archive.
Yes they do. See above.
> * Then, you must use a REAL static hash function for determining how
> this split is going to happen. If you don't know hash functions well,
> someone else surely does. Feel free to ask for advice!
No. Humans interract with the archive. It has to be usable by humans.
If only programs did the work, then I'd agree. But not all procedures done to
the archive are handled by automated programs.
Think about an advanced language, which has built in support for hashes(perl,
c++, java). No programmer can see how the hash works, and therefor, it
doesn't matter how it works. However, everyone can see how a hash-pool works,
so there must be some consideration.
> If anybody here has objections to these points, we'd better sort them
> out as I have very strong confidence in these.
They all fail, because you forgot that humans must interact with the files in
the pool.
> Can please somebody tell me why this is not on a CVS server? Why can't
> people contribute patches to it? Why is this development discussion
> going on in private instead of in debian-pool? This is too important
> to leave to the personal decisions of a handful of eleet.
Because it isn't ready yet? Almost all projects start out with one or a few
people working on them. This allows the api, interface, scope to be decided
upon, without a lot of political bellyaching. Once the design is set, then it
can be released.
(note: design != feature set)
> I've asked for the specifications of dinstall. I've also asked
> if I should package dinstall. Nobody answered. I'd like to contribute
> to package pools, so I await your comments on this.
Dinstall is in cvs. No one answer, because "God helps those who help
themselves."
> [1] This kind of refusal to co-operation is not good for Debian.
Refusal to look for information is not good for Debian.
----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS d- s: a-- c+++ UL++++ P+ L++++ !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-----END GEEK CODE BLOCK-----
----BEGIN PGP INFO----
Adam Heath <doogie@debian.org> Finger Print | KeyID
67 01 42 93 CA 37 FB 1E 63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-----END PGP INFO-----
Reply to: