Opened 10 years ago

Closed 10 years ago

#87 closed enhancement (fixed)

make debirf do good guesses about the choice of distro

Reported by: dkg Owned by: jrollins
Priority: major Component: debirf
Keywords: debirf Cc:
Sensitive:

Description

At the moment, debirf assumes everything is debian. It uses the debian archive keyring by default (/usr/share/keyrings/debian-archive-keyring.gpg), and pulls from a debian mirror (http://mirrors.kernel.org/debian).

It would be more friendly to users of other distros (e.g. ubuntu) to make debirf cleverer. Here's a couple proposed ways of doing so:

  • if no keyring option is supplied (--keyring=), choose the first file that matches /usr/share/keyrings/*-archive-keyring.gpg -- and report the name of the one chosen.
  • if no mirror is supplied by the user (DEBIRF_MIRROR environment variable is unset), first test to see if the requested distro is available by the return code of:
    wget -O- -q "http://mirrors.kernel.org/debian/dists/$DEBIRF_DISTRO" >/dev/null
    
    If the requested distro is not available, try stripping off the first chunk of the name of the selected keyring as $OS_NAME, and repeat the same test with:
    wget -O- -q "http://mirrors.kernel.org/$OS_NAME/dists/$DEBIRF_DISTRO"
    

If these steps are implemented properly, they should let debirf work relatively cleanly for (at least) ubuntu users without them needing to read the man page in detail. It also opens the door for running debirf against other debian-derived operating systems.

Change History (10)

comment:1 follow-up: Changed 10 years ago by jrollins

after thinking about this issue a bit, I have a couple of comments.

the DEBIRF_KEYRING is tied to two things: the DEBIRF_DISTRO, and the RUN_DISTRO that debirf is being run in, which are themselves related. DEBIRF_KEYRING is required to verify DEBIRF_DISTRO, but DEBIRF_KEYRING is only (readily) available if DEBIRF_DISTRO matches RUN_DISTRO.

I think that the DEBIRF_DISTRO and DEBIRF_KEYRING variables should be specified in the profile debirf.conf. This is really the best way to keep consistent profiles.

The previous 2 points lead me to the conclusion that the best way to deal with this is to have different debirf.conf files for different distributions. This means a different debirf.conf.default and example profile debirf.conf files for debian and ubuntu respectively. It makes since to make a whole bunch of fancy checking, since even if you do, you still won't be able to verify a lenny debirf on an ubuntu build platform, and your fancy checking will be undone.

My final point is that I don't think the keyring should be specified as a command line parameter. Specifying it as a command line parameter is inconsistent with how other parameters are specified in debirf, and is therefore confusing. It should be specified in an environment variable, and there for put in the debirf.conf only.

comment:2 in reply to: ↑ 1 Changed 10 years ago by jrollins

The previous 2 points lead me to the conclusion that the best way to deal with this is to have different debirf.conf files for different distributions. This means a different debirf.conf.default and example profile debirf.conf files for debian and ubuntu respectively. It makes since to make a whole bunch of fancy checking, since even if you do, you still won't be able to verify a lenny debirf on an ubuntu build platform, and your fancy checking will be undone.

sorry, I meant that it *DOES NOT* make sense to do a bunch of fancy checking to determine the keyring file, since it will be undermined by the default DEBIRF_DISTRO.

comment:3 Changed 10 years ago by dkg

I'd really prefer to avoid two separate releases of debirf. The tool should be able to work cleanly with any apt-ified, .deb-based distribution that includes a reasonable set of packages.

comment:4 Changed 10 years ago by jrollins

I hear you about wanting to avoid separate releases. However I think the statement "the tool should be able to work cleanly with any apt-ified, .deb-based distribution" doesn't make sense and misses the issue. I think some more clarification is in order. I also think we need to change our terminology to come in line with debootstrap. definitions:

I now realize we're using the wrong terminology for things. DEBIRF_DISTRO should in fact be DEBIRF_SUITE. etch, lenny, gutsy, etc., these are all SUITEs in debootstrap terminology. I'm going to make some definitions here that I think we need to move to:

  • DEBIRF_DISTRO: the target distribution of the debirf image (debian, ubuntu, etc.)
  • DEBIRF_SUITE: "version" of distribution, implies DISTRO (etch, lenny, gutsy, hardy, etc.)
  • RUN_DISTRO: the distribution of the host system that debirf is being run on (debian, ubuntu, etc.)

Compatibility with the RUN_DISTRO should be completely handled by apt, ie. apt should pull in debootstrap and the other tools needed to run debirf and the various modules.

The supported build suites (DEBIRF_SUITE) are determined primarily by debootstrap and the target suites it can build. At the moment these are ("ls /usr/share/debootstrap/scripts/):

Debian:

  • etch
  • lenny
  • potato
  • sarge
  • sid
  • woody

Ubuntu:

  • breezy
  • dapper
  • edgy
  • feisty
  • gutsy
  • hardy
  • hoary
  • warty

I should point out that supporting all these suites is not trivial. There are more almost 20 different build scripts. Building debirf is not unlike running debootstrap. We want to avoid the complication of maintaining a bunch of different build scripts for different suites and distributions.

In practice, this means two things, that I can see:

  1. the DEBIRF_KEYRING relevant to the desired DEBIRF_SUITE (and DISTRO_DISTRO) has to be available on the RUN_DISTRO to do debootstrap verification. This is the point I was trying to make in the first comment. This is difficult if DEBIRF_DISTRO does not match RUN_DISTRO.
  1. the default INCLUDE packages need to be available in the default component of the DEBIRF_DISTRO. This shouldn't be too hard to accomplish since there appears to be only one problematic package that can be easily replaced (see #88).

One way to solve the first problem would be to write in lots of tests to determine what the RUN_DISTRO is, and change the defaults accordingly. Another would be to provide different debirf.conf and debirf.conf.defaults files for each RUN_DISTRO that would specify default DEBIRF_SUITEs that are compatible with the available DEBIRF_KEYRING. Another would be to provide a single set of files, and provide good comments and documentation for users of different distros. This last one gets my vote. I personally think it's ok to require the user do a little bit of work, especially since it will save us lots of headaches.

comment:5 Changed 10 years ago by dkg

You could write a simple script to guess what DEBIRF_KEYRING to use:

if [ -z "$DEBIRF_DISTRO" ] ; then
 case "$DEBIRF_SUITE" in
  breezy|dapper|edgy|feisty|gutsy|hardy|hoary)
   DEBIRF_DISTRO=ubuntu
   ;;
  *)
   DEBIRF_DISTRO=debian
   ;;
 esac
fi

This would be visible, simple, and easy to expand as new suites get added. debian could always be the default, and users could override explicitly with an environment variable if they needed to.

comment:6 Changed 10 years ago by jrollins

That seems like a reasonable approach. Is there any reason to define DEBIRF_DISTRO, though? Is that not implied by DEBIRF_SUITE?

Here's what I say we do:

  1. remove the DEBIRF_KEYRING line from the debirf.conf.default in favor of guessing in debirf.
  2. in debirf, use a guessing function similar to what you suggest, or instead of testing on and defining DEBIRF_DISTRO, do the same but for DEBIRF_KEYRING, since that's ultimately what we want to find out.
  3. put something like the following in the debirf.conf files:
    # what keyring should be used to verify the debootstrap?
    # on Debian:
    #DEBIRF_KEYRING="/usr/share/keyrings/debian-archive-keyring.gpg"
    # on Ubuntu:
    #DEBIRF_KEYRING="/usr/share/keyrings/ubuntu-archive-keyring.gpg"
    

How does that sound?

comment:7 Changed 10 years ago by dkg

I'd say it makes sense to just guess at DEBIRF_DISTRO, and then to derive DEBIRF_KEYRING from that:

DEBIRF_KEYRING=${DEBIRF_KEYRING:-"/usr/share/keyrings/$DEBIRF_DISTRO-archive-keyring.gpg"}

comment:8 Changed 10 years ago by jrollins

but what if we want to support a different distro down the line, and it's keys are specified in the same format?

But there are other problems. Can you build lenny on Ubuntu and verify it with the ubuntu keyring? If not, then the above solution won't work either, since we still specify lenny as the default suite. the DEBIRF_MIRROR is also dependent on these choices as well. it seems to me, actually, that all of these variables need to be specified together:

  • DEBIRF_SUITE
  • DEBIRF_MIRROR
  • DEBIRF_KEYRING

should we test for the distro and set all of those variables together? supporting ubuntu is turning out to be a bit of a pain in the ass.

comment:9 Changed 10 years ago by dkg

If we want to support a different distro, and they've put their keyring in an odd place, we can expand that DEBIRF_KEYRING= line to be more sophisticated when we run into that problem. Until then, there's no need to make it more complicated.

Since the end user is able to override any of these variables with their own environment variable anyway, you could still create an gutsy debirf image from a lenny host system, simply by fetching the keyring locally, and providing a path to it in the system environment.

Since we can derive a decent default DEBIRF_KEYRING and DEBIRF_MIRROR from a known DEBIRF_SUITE for the distros we currently know how to support, it would make sense to do so, and not require end users to have to know those details if they want to go with the default.

comment:10 Changed 10 years ago by jrollins

  • Resolution set to fixed
  • Status changed from new to closed

fixed in 0.18-1 [1017]

Note: See TracTickets for help on using tickets.