Hello On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote: > 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.
As you probably know it has been expressed before. > 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. Might be a good alternative, but see below. > 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. This is the problem. How do you make sure that the package is buildable on the architecture without building it? And if you have built it why not just add it to the archives. :) So you still need a buildd. :( > The problem of syncing with testing is also reduced; now we need only > make sure base is synced across archs. What you really are saying that for some arches we only support base and essential (and some more). Everything else is provided as source debs and not supported, even if it might work. I mean the source is available currently and the only thing you say is that we should only build some parts of that port. > 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. This will help yes. > 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) Nice. > 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 * Not possible to tell if a package is buildable on a specific arch or not. > 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? Nice idea, but I do not really see the benefit, more than on ftp disk space and security update speed. Regards, // Ola > -- John > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
