Re: Packages file (long email) [WAS: Splitting Packages]
> You need to read 3 lines from a text file that is fully dinamic. They
> might be there, they might not be.
You will need to read them anyway. You cannot jump to the next entry
directly, you'll have to continue reading until you encounter two
consecuitve newlines.
So the best way to read the file probably is to read a whole entry,
then split it into lines not starting with a space (these are appended
to the previous line) and then deal with these attributes.
You gain almost nothing by having just a single line instead of three
lines. You'll have to read 10 chars less, and split two times less,
that's all.
> here is where I think you can gain something even if is
As stated above, you need to read the other lines lines anyway.
You usually won't stop on the Line starting with "Depends:", because you
have to go to the next package anyway. So you slurp until the end of the
whole package info, then search for the newlines-not-followed-by-space
and break the string there.
> So that can be another step to improve the handling of the archive.
> I also noticed sub-sections used only by one pkg.
sub-sections are no longer existant in the archive actually. We have the
pool now. Subsections are only used for package manager frontends (and
for freezing base ;)
> I see your point but IMHO how will you define exactly the boundaries???
There is no need to. A package can be in multiple of these sections.
Only if a package is in most, it should move to the special "shared"
section to reduce bandwidth.
> >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.
Well, that's what security.debian.org is for. One could have that on
update-everyday...
The point is that people running testing with single packages from
unstable will download BOTH testing and unstable package lists on every
update. That's quite a waste of bandwidth ;)
So if i'm running testing and maybe "galeon" from "unstable", i probably
don't want to update to _every_ version of galeon. So maybe it would be
convenient to have "apt-get update; apt-get upgrade" update testing
only, and "apt-get -t unstable update" update unstable on request only.
But this has to be configureable.
> 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, that will break apt-zip etc. Think of those poor users having to
download these files on expensive and/or slow lines (and these are the
users your changes are designed for)
They'll download, go offline for installation, just to get said that
they're missing dependencies and have to get more files...
You're actually breaking the best feature of apt that way...
> Oh well sorry... my fault.. I didn't copy & paste the entire descrition ;)
i wanted to say that you cannot remove much data from the Packages file,
because you'll need most, except for the Description - and lot's of
people will still want the description, too...
> >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
Yes, but it has to unpack it before being able to resolve it's
dependencies, which is BAD, because it will not work on batched
transfers. See, people will have apt output a download-todo-list, bring
this file to another system, wget the packages, put them on ZIP/CD-RW,
carry them back to the other machine and have apt install them there.
This will no longer work.
> 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.
I think it's better to just split out the game section, and maybe define
a lower update-interval for it. I don't need to update my games
everyday.
Having diff's for the Packages files and splitting it, so i can deecide
if i need games on my server, and roxen challenger on my standalone
not-networked pc should improve things much more.
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: