Re: intent to package mrename
Bdale Garbee writes:
> The package meta-data explosion is a real problem, and one that we
> need to work on creative technical solutions to address. Both the
> download times over slow links for Packages information and the VM
> requirements of our package management toolset are getting out of
> control. The best answers I have heard so far are of the "split
> Debian into a core and various optional sections" variety, and they
> still feel "icky" to me.
Absolutely. I've been thinking about this off and on but don't have
anything creative. While I like the splitting-of-core-debian idea in
theory, I fear that the `what goes in core?' arguments would never
end. (for example, consider X.)
In response to the problem of downloading the entire Packages just to
apt-get install one thing, perhaps the whole list-of-availible
packages can be rethought. Instead of caching Packages locally, we
could have apt-get fetch the metadata for the package in question (and
only the package in question) when it needed to be installed. Updated
metadata could be filed away by date so that only the relevant entries
needed to be fetched upon apt-get update.
Of course, if the user wanted to browse all packages, they still
should have that option. If they wanted to search, people with the
availible resources could provide ``metadata mirrors'' so that the
person behind the slow network link could just send the search term
over the wire and get a list of matching packages back.
Impact on our mirrors would have to be considered, of course. One big
file is cheaper than many small files, and running apt-get search
queries on behalf of users (while entirely optional) would take up
resources. There may be technical/logistical issues to be worked out.
I'm just going off the top of my head here. Has someone suggested
something like this before? I get the feeling I'm rehashing package
pools.
> However, there is nothing in Debian policies or history that
> suggests that we should be giving someone a hard time about
> packaging some additional utility regardless of whether it
> duplications functionality solely on the basis of meta-data bloat.
> Why pick on this poor soul?
Agreed. Let's not put band-aids on broken arms.
--
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Reply to: