On 9/05/10 8:50 PM, Neil Williams wrote: >> I think we could have a single baked repo that has everything included >> -- all packages configured the same as grip. >> That would be the base repo for developers to get started with the >> development process, etc. >> Any other customised configurations would require a separate/local >> repository. >> > OK. I'm extending apt-grip to have architecture-selection support. > It'll be useful in other areas too. > > 1. apt-grip -a will (naturally) not install the downloaded packages. > 2. it's basically the same process as multistrap, but the packages are > fed to emgrip upon download. > 3. apt-grip already has dpkg vendor support to select Baked. > > I've tested with a simple reprepro file (this is where the defaults > issue comes in, with whether we support testing, migrations and the > rest as well as how to get the matching sources into the repo). > > Then something like this to generate a filter to get the sources: > $ reprepro list lenny|sed -e 's/.*: \(.*\) .*$/\1\t\tinstall/'|sort -u > > conf/pkglist > > There is a way for reprepro to then "update" from Debian to get the > relevant sources. > > Once reprepro has included the baked packages, multistrap can use that > repo. > > I don't want multistrap itself to gain this support because it brings > in a dependency on emgrip which in turn depends on lots of devel type > stuff, gettext, debhelper etc. as well as reprepro. So this will be a > section of documentation for the Baked website, with sample reprepro > files. > > As for a repo on www.emdebian.org/baked, what I'm thinking is that I'll > make a lenny repo available with the packages (and dependencies) you > mentioned but leave Squeeze until it's released. The reasons are that > the HARD part of handling testing is handling the migrations and > updates. reprepro simply halts if ANY packages try to "update" to the > same version with a modified file, so you cannot run this baked process > repeatedly and expect 'reprepro includedeb' to "do the right thing" - > if package A has not been updated in Debian since your last run, > reprepro will halt the entire import, never getting to package B which > *has* been updated and would be handled by reprepro without difficulty. > Each time you "bake" or "grip" a .deb package, you change timestamps > and thereby change the checksums, so reprepro fails on it's (otherwise > very important) verification step. The hard part is working out which > packages in an update will be accepted by reprepro and which need to be > ignored, then working out if any of the updated packages have changed > dependencies and now depend on missing packages, whether some of your > existing packages have been removed since the last update etc.etc. That > is why we put this problem up for a GSoC project. It's hard. > > Once I have it working and the docs are updated, a local repo could be > used to handle packages from testing or unstable - whether you choose > to simply dump the previous repo before updating or try to do the > complex work of cherry-picking the files that can be updated is up to > you. > > I'll email the list when a Lenny Baked Grip is available. >
I'm happy enough to use Lenny for Baked packages. I was using Lenny for a development host but I upgraded to Squeeze/Unstable as I emgrip isn't in Lenny, and bringing it in would install a lot of libraries from unstable which I tend to avoid when running Stable. Will I need emgrip to create Baked rootfs ?? I assume not if multistrap can just access the emdebian Baked distro. But for anything not in emdebian Baked that I want to modify, I will need to use emgrip and thus need to use a testing/unstable development host. Yes ?? I guess my question is: is Baked intended to be usable on a Lenny development host or is it designed for a Squeeze development host ?? Cheers, Brendan. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
