Re: Package Pool Proposal
Guy Maor wrote:
> The hashing. First letter of package is clearly not a good choice. Of
> course I can use a real hash function, but I was hoping that I could
> come up with something simple enough to calculate in one's head.
> Otherwise downloading a single file becomes a bit more difficult.
> Perhaps this isn't that important, and users would have to query to
> database to find the real path?
I think it's important there's a simple heuristic to figuring out what path
a package is in. I can't count the times I've needed to navigate the archive
hierarchy by hand to find a file.
> No section hierarchy. Categorizing our enormous package set with one
> section and priority axis is ridiculous.
Agreed.
> I regard both these fields
> as practically useless. We need to allow for a package to exist in
> multiple sections. A package-selection program could then show all
> gtk clock programs for example.
That sounds very similar to the keywords idea. I think that's a good idea,
but I still think there's room for section information that lets the
packages be displayed in some sort of hierarchy in apt frontends. Maybe not
using the section in the archive will let us switch to using a hierarchical
section later.
> Priorities might not be needed any more.
Priorities still have a great deal of value, as a way to ensure you have
everything that's in a standard unix system, and as a way to filter out
extra stuff. But then, they've never had anything to do with the archive
anyway.
> Information in the database. Everything should be in the database.
> Copyrights, upstream URLs, changelogs, content listings, dependencies,
> etc. The package web pages should be generated dynamically from the
> database.
Well, just don't bite off more than you can chew. I'd rather see a basic
package pool with an expandable database in a month, than all this stuff in
a year. :-)
--
see shy jo
Reply to: