Re: Let's shrink Packages.xz
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> But the problem with lots of small packages is not that the Packages.xz
> has too many bytes.
> It's that the packaging tools, UIs (for users and developers), and
> humans, need to think about too many packages.
> This makes packaging tools slow, UIs cluttered, and humans confused.
So we need to figure out how to solve that problem. But "don't package
things" is not a good solution to that problem, obviously, and "don't
package small things" or "don't use a packaging structure that works well
for our tools" aren't much better.
I think it's important, when looking at a problem like this, to
distinguish between problems that are fixable via a change in policy
versus problems that are only deferrable. This is a problem that's
deferrable by changing what and how we package, but not fixable. The
amount of software in the world is going to continue to grow, and Debian
is hopefully going to continue to grow with it, which means that the
package list is going to get longer regardless of our policies around
packaging small things. So all those problems are going to happen no
matter what, which means we should find better solutions to them.
Packaging tools need better, faster algorithms. UIs need better
information hiding: we have a lot of that already with, for example,
shared libraries, which the average user never has to see (since they're
pulled in via other packages the user wants), and therefore doesn't care
how many of them there are in the archive. Data formats need to deal with
large numbers of packages better. Because, no matter what, we're going to
have to deal with large numbers of packages.
And, as a bonus, if we solve the underlying problem, we can use a more
natural packaging strategy where an upstream corresponds to a package,
without the complexity of artificial lumping together of packages that are
actually distinct.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: