Re: Packages file (long email) [WAS: Splitting Packages]
Erich Schubert wrote:
Well, first thing: you'll get dozens of replies to postpone this
discussion until the release of woody and fix bugs instead ;)
ehhee well people are welcome to partecipate but noone is forced to ;)
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?
I don't know hounestly. For sure someone else will answer this.
Depends: +base-files (>= 2.1.12), !libc6 (>= 2.2.4-4), *bash-completion
[CUT]
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.
Well my point is:
Depends: x, y, z
Pre-Depends: a, b, c
Conflicts: d, e, f
You need to read 3 lines from a text file that is fully dinamic. They
might be there, they might not be.
reading instead one line (that we can force to be there even with no
entries):
Depends: +x, -y, =j, blablablabla
here is where I think you can gain something even if is
1) not really human readable
2) you might loose soemthing parsing the +=- etc..
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, ...
Ok that was just because admin,base etc are called Section: in the
Packages file. So I didn't any specific term for main contrib etc. ;)
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.
So that can be another step to improve the handling of the archive.
I also noticed sub-sections used only by one pkg.
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.
I see your point but IMHO how will you define exactly the boundaries???
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...
Hounestly I don't see the point here. In this case you might also need
an override system for security updates.
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?
I made a point that probably was not too clear.
try to imagine:
you want to install pkg a that depends on b that depends on c
b and c are only in Available.
apt will inform you about pkg b and ask the permission to download
(let's say that you can configure apt to do this automatically)
after downloading pkg b apt can check the dependencies of pkg b
and request for pkg c and so on. It's a question of small loops.
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.
Oh well sorry... my fault.. I didn't copy & paste the entire descrition ;)
2) can be used to correct broken dependencies (read above)
Doesn't work.
It does partially because apt will be able to find a pkg in the archive
even if the realtive Packages file is not downloaded via sources.list
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...
True. Like we say in my country: You can't have a drunk wife and the
bottle still full of wine.
Somewhere you need to cut something but don't forget that in case
your system downloads all the Packages files than you can.
It's only question on how flexible you want to be within your system.
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...
That's for sure, but consider that even if I have to download the
Available.gz file I might save some other hundred KB not downloading the
game section for instance.
Greetings,
Erich
Thanks
Fabio
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: