On Sat, 29 Aug 2009 19:30:45 +1200 Donald Gordon <don@dis.org.nz> wrote: > > Description: server-side support for Emdebian Grip > > Provides server-side scripts to manage and update > > the conversion of Debian packages into 'gripped' packages > > that have no Debian documentation, manpages or infopages. > > > > If you have a lot of packages to add, centred on a particular area of > > functionality or maybe an internal set of packages, use > > emdebian-grip-server to host your own repository and scripts like > > multistrap to add that repository to your installed Grip machines from > > the start. You don't have to support all packages or all architectures > > in your own repository. The scripts will try and help you create a > > reprepro setup that you can then tweak. > > > So that would actually be okay for my use; I have a (non-grip) machine > with lots of disk which I installed em_autogrip on. The manpage says it > uses unstable or testing; I wanted to grab packages from lenny, and got > confused. A simple example of how to use it would be most welcome. Lenny is an awkward issue but could, theoretically, be easier as it is not updated. There isn't an example for a simple reason - it hasn't been done and it isn't the "Debian way". The Debian Way is always put things into unstable unless there are release-critical issues. This underpins a lot of how reprepro expects to work and therefore em_autogrip too. e.g. on www.emdebian.org/grip, lenny is only updated via stable-proposed-updates. Lenny, on that server, was created as stable from the previous testing - there never was an update of "just lenny". Therefore, adding packages directly to "lenny" is a strange thing to do. There are various places in em_autogrip where 'unstable' is hardcoded into the script but *most* of these are related to "britney" which is the mode that migrates packages from unstable into testing. I say most, I cannot be sure that all such instances are covered. Watch the em_autogrip output *carefully*. (Probably best to create a distribution called unstable anyway - the defaults for when em_autogrip sets up the distribution configuration are for unstable only.) There are some nuisance errors that come up in the output - generally trying to include the same package twice with a slightly different file - you can ignore most of those. A lot of the changes you'll need will be in the reprepro configuration, so you'll get to know reprepro (1) quite well too. :-) Building a new Grip repo takes time and should not be attempted in a single go, that is why we use a filter repository and you should be careful which and how many packages are added to the filter per run. "builddeps" mode is also unlikely to function properly if the only information available is for stable. Other problems are differences between package SONAMEs between unstable and lenny. The machine RUNNING em_autogrip should be (or have available) the apt sources data for the specified suite. (I'll add that to the em_autogrip manpage if it isn't there already.) This prevents issues where you need libfoo0 in lenny but unstable has already migrated to libfoo1 - this problem becomes even more acute when libfoo0 had a source package called foo0 and libfoo1 has a source package foo1 - at which point, unstable will no longer contain sources data for foo0 and things start to break. > apt-grip is neat but my grip machine has insufficient disk to use it, alas. > > The text of your email would do well on the website, too. Feel free to create / add to a Wiki page. (It's better if wiki pages are written by those who are learning this stuff rather than those who are advising - that way, the wiki content is more useful to others who want to learn.) This has always been a goal of em_autogrip but it has yet to be tested fully, so your experiences will be useful - please record them on the wiki and file bugs as appropriate. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpbhKYD47Uii.pgp
Description: PGP signature