Re: Packages file (long email) [WAS: Splitting Packages]
Erich Schubert wrote:
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 ;)
yes Im aware of the pool. But I like the idea of having subsections to
classify pkgs. That's one of the reason why Im pushing in that
direction. I think that a good restructures can improve the system in
several ways. More than what I discussed before, the first example that
come in my mind is the possibility to build CDs set based on
subsections. CD set for developers, CD set for whatever... just to make
an example.
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.
Can you point me to the previous posting you made about this discussion?
It seems an interesting idea.
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.
Ok got it ;)
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...
Yes right. I didn't tought about this scenario.
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...
Well I was just removing some redundat information. For instance Arch:
can be removed because the same info is in the file name.
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.
Like you pointed out before. I agree. I didn't thougt about this
scenario. And yes is BAD. Do you have any suggestion on how to handle
this situation?
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.
Well I could say the same for developer section. I don't use it on every
machine. My idea is to bring up a general scheme and not just a patch
for one section.
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.
yeah and this is my point but applied to the entire archive for all
combinations.
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: