[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Baked repository

On Sun, 09 May 2010 09:23:19 +1000
"Brendan Simon (eTRIX)" <brendan.simon@etrix.com.au> wrote:

> On 8/05/10 8:22 AM, Neil Williams wrote:
> > Are there any Baked repositories ?? Baked-Grip or Grip-Baked ??
> >> It depends how many packages you want to have and how often you
> >> want to update packages in your repository against those in Grip.
> Things for network devices (e.g. a router, firewall, ntu, etc).
>     * glibc, eglibc.
>     * dash and probably bash.
>     * snmpd
>     * an ssh server (openssh-server, or possibly dropbear).
>     * openssl
>     * a web server (apache, etc).
>     * The possibility for some other scripting languages (perl,
> python, php) -- a low priority at this stage.

perl will be brought in anyway as a dependency - you cannot avoid perl
in Debian without using Crush (which, in turn, is currently bust). So
all of this relates to Emdebian Grip (Baked).

(Yes, I need to update the webpage with all of this too ....)
> > I have local computing power and local storage which can be brought
> > to bear and then rsync'd to the Emdebian server or, more likely,
> > space on another server to which I have access. (The
> > data-freedom.org site in my sig used to host a repository, it can
> > be rejigged.)
> 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

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

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

I'll email the list when a Lenny Baked Grip is available.


Neil Williams

Attachment: pgpI0paCFusEk.pgp
Description: PGP signature

Reply to: