Re: Baked repository
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.
Reply to: