Alternative: Source-Centric Approach [w/code]
As I have been reading the discussions about the SCC proposal for
etch, it seems that these are the main problems:
1) Difficulty with, and speed of, buildd systems
2) Difficulty of syncing testing across all archs given #1
3) Difficulty getting security releases out in time, given slow archs
4) Space constraints on mirrors
I'm throwing out a different idea, and I'm backing it up with code. I
have thought about it some, maybe there are huge holes, but let's see.
I propose that we split things along these lines: binary+source (B+S)
archs and source-only (SO) archs.
B+S archs will be essentially like we have now -- .debs and sources
for every package in Debian are available.
SO archs will be handled exactly like we do now, EXCEPT that we will
not distribute .debs for most packages. I expect that we will
distribute .debs for base and build-essential, mainly -- the minimum
someone needs to install a working system and build more packages.
What will that mean for our problems?
The speed of buildd systems mostly becomes irrelevant. They will
still have to keep up with base (the set of .debs that we do
distribute for a SO arch). Anything past that is there just for QA
purposes -- to make sure packages are buildable on these archs, and
would be optional.
The problem of syncing with testing is also reduced; now we need only
make sure base is synced across archs.
The problem of getting security releases out in time is also reduced;
source packages are enough for these archs. If there's a hole in a
base package, we'd want to provide .debs for everyone, but these
packages aren't going to be the KDE-style mammoth ones.
And finally, this would be a huge win for mirrors. We would have far
fewer space constraints, and adding a new arch would be easier.
What would this mean for users?
Basically, packages install slower on these archs. I have developed a
demonstration tool called srcinst, available from
http://people.debian.org/~jgoerzen/srcinst/. srcinst is capable of
filling all of a package's dependencies and build-depencies solely
from source. It will use apt-get -b source to build .debs, then
evaluate (and build, if necessary) their deps, then install them with
dpkg -i. In short, very similar to apt-get install, except it never
downloads a .deb from anywhere for any reason. (Most other tools
don't go this far, and still require .deb downloads for build-deps, or
don't handle deps at all)
This gives us the benefits of smaller mirror infrastructure that
projects like Gentoo have, while still maintaining all the advantages
of dpkg/apt.
What are some downsides?
I can see a few:
* Longer package install times, obviously
* Difficulty of dealing with dependency loops
(possible solution: include one .deb from each loop in the dist)
* Disk space requirements to build packages
More on srcinst:
Here's an example for epic4, which looks like this:
Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.4-1), libssl0.9.7,
epic4-help (>= 1:1.1.7.20020907)
Build-Depends: debhelper (>= 3.4.8), libncurses5-dev, libssl-dev
Let's assume I have libssl-dev installed and libc6 installed, but no
ncurses5.
So, I run "srcinst install epic4". Here's what it does:
1. Looks at the build-depends, sees that we are missing
libncurses5-dev. So:
a. Grab and build the source package corresponding to
libncurses5-dev.
b. Examine the deps in libncurses5-dev.deb. Notice that it deps
on libncurses5 (which we just built), so dkpg -i libncurses5
and then dpkg -i libncurses5-dev.
2. Build epic4 itself.
3. Look at the deps in the epic4 .deb. Notice that it deps on
epic4-help.
4. Build and install epic4-help.
5. Install epic4.
The srcinst code is very hackish, ugly, and quick. I just wrote it
since yesterday as a proof of concept. So:
* Make sure yuo rnu it as root (no support for fakeroot/sudo yet)
* It can't resolve dep loops
* It can't handle !arch strings in deps accurately
* It spews debugging info to stdout
* It uses /var/cache/srcinst for its working area. Make sure /var is
free enough.
So, what do you think? Could this work?
-- John
Reply to: