Re: Packages file (long email) [WAS: Splitting Packages]
Well, first thing: you'll get dozens of replies to postpone this
discussion until the release of woody and fix bugs instead ;)
> The first thing that poped up to my eyes was the entry "Essential: yes"
I think a maintainer can set the priority of a package himself, whereas
the essential flag has to be added by the mirror maintainers, is that
correct?
If a maintainer sets the essential flag on a package i fear that apt-get
will automatically install that package... This would be abuseable.
Of course one could modify dinstall to require confirmation for
"essential" priority, too. But the overrides-mechanism is there already.
It's the same mechanism for Tasks, too, i think, so the old one wouldn't
become obsolete; we would get another mechanism there...
BUT i do not know for sure, how this is handled right now. I'm not an
insider on that issue.
> Depends: +base-files (>= 2.1.12), !libc6 (>= 2.2.4-4), *bash-completion
Well, i like that, but it will be more difficult to read by humans;
and i'm not sure how much speed gain this will give. I doubt this
will do much; and downloading via gzip shouldn't be much faster either.
See, the easiest way to parse the packages file is just splitting at the
colon, strcmp the left side, pass it to the appropriate handler. That's
not very slow... I fear that removing the first char from each entry,
comparing it, then calling the appropriate handler might even be slower.
(different types of dependencies are mixed here, whereas they were
separated in the old style)
> In this way is possible to save some lines in the file and the parser can
> benefit from that.
I don't think the Parser will benefit at all. It will be more complex
and more difficult to understand for sure. It might even be slower.
> The next step in my idea is to split the Packages file in several files
> according to Section and Priority.
First of all: Sections are: main, contrib, non-free, non-US/*
Subsections are admin, base, web, ...
I had thought of that, but i found it not useful right now.
The subsections we have are badly balanced and not consequently used, nor
they are clear cut. If we had different sections, that would make more
sense. Subsections as of right now are _useless_ IMHO.
As written by me a few days ago, we could split the packages into
packages files for "server", "desktop" and "shared". That would make
much more sense. As does the section "devel" maybe.
There comes one suggestion i have for APT... maybe i should file a
wishlist bug, but i'll have to check if apt doesn't already support
that... Sometimes it would be great to "limit" how often a Packages list
gets updated.
People running testing with a few packages from unstable might want to
update their testing lists on each "apt-get update", but their unstable
lists only once a week... But i'm not sure either, how many people
actually will use this...
Another suggestion would be splitting package searching and dependency
handling in multiple "layers". So let's say a user runs "desktop"+"shared"
primarly, and "devel"+"server" secondary.
And request to install a package is first tried to fulfill within the
primary Packages tree, and only if it cannot be fulfilled there, the second
tree will be parsed (!) and evaluated.
This should give a speedup for everyday use, while not slowing down much
on extended useage.
> The solution is to have in /main /contrib /non-free a file called Available
> that file should contain one entry per line and every line should look like:
>
> section/priority/pkgname/verion
That will not suffice.
You are missing the dependencies here.
See, app a, requires library b (only in Available), but library b
requires library c. How do you know you need to download library c,
too?
Well, you'll end up with a Packages files not missing much except for
the extended descriptions... and i don't like that either, because i
sometimes want to check the descriptions of packages i'm forced to
install due to dependencies.
> 2) can be used to correct broken dependencies (read above)
Doesn't work.
> 3) fast search over the entire archive even if a specific
> section/priority is
> not present in the sources.list
But you cannot search for Descriptions...
> 4) diffed against the old one can be used to decide with Packages files
> should be downloaded according the sources.list (this can be an
> interesting option to analize in order to reduce network load probably
> even for mirroring purpouse)
Well, checking the modification date of the Packages file should be
fine, too... but expect most Packages files to change every day...
Greetings,
Erich
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: