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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
