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 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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpI0paCFusEk.pgp
Description: PGP signature