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

Re: package requests for grip



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: pgpjSq9znWJQW.pgp
Description: PGP signature


Reply to: