Improving the distro packaging and installation experience

[James Westby]

On (15/01/07 12:54), Lars Wirzenius wrote:
> On ma, 2007-01-15 at 00:05 +0000, James Westby wrote:
> > On (05/12/06 16:45), Mark Shuttleworth wrote:
> > > For APT-based systems, we already have
> > > http://bazaar-vcs.org/packages/debs/ and I would like to understand if
> > > this is sufficient for Ubuntu AND Debian, and for multiple releases of
> > > those distros, or if we need to maintain current packages for the
> > > current stable versions of each of Ubuntu and Debian. For example, do we
> > > need a dapper, edgy, feisty, and sarge and etch, versions of the package?
> 
> I'm afraid it would be a good idea to count on things being different
> enough that it's best to build different versions of bzr for different
> debianish systems. For example, the Python policy for Debian sarge and
> etch is significantly different, and something that works on etch won't
> work on sarge, at least without installing a bunch of backported helper
> packages, some of which may need backporting first.

I was going to ignore sarge for now, unless someone wanted it and was
willing to backport bzr properly.

> [James, speaking of his nice builddeb plugin]
> > It's not perfect at the moment, they're not signed, they're built in an
> > unclean environment, and I had to turn off the testsuite run due to a
> > strange error I didn't have time to investigate. I'm going to try and
> > sort out these wrinkles in the next week.
> 
> Building in a clean chroot is (obviously) necessary, but luckily also
> very easy, thanks to pbuilder by Junichi Uekawa.

Yes, I was going to set up a cowbuilder setup for this, but that
requires root access, so I wanted to think it through first.

> I use it in the
> Unperish[1] script I just wrote to do builds (and more) of my own
> programs, feel free to pinch any code you want. (I didn't want to use
> builddeb, unfortunately, since I'm uncomfortable tying my build process
> to bzr, so I wanted something that uses bzr only to export the sources.
> I'm looking forward to benefit from your work on bzr to make that
> easier. :)

I was looking at your script today. It is very Lars orientated, but that
is understandable. It is solving a different problem, but it can call
builddeb at least.

It actually has some things in common with something that Martin F.
Krafft inspired me with. This is a set of scripts with a uniform
interface for accomplishing common tasks. The idea is that you can write
backends for any system so that it is transparent to the user what is
going on. It was more aimed at Debian work, QA, NMU sort of stuff, but
there's not even the start of a design yet, so it could go anywhere. It
would also be completely extensible so that you can add your own scripts
to do anything you want, like the tasks that are currently in unperish.
I don't know yet whether anything will come of it, but if you wanted to
discuss it and try and improve the "design" then I would be happy to.

Incidentally, I have fixed the things that you mentioned on IRC the
other day. They are in the 0.14 branch though I'm afraid, so it wont be
too easy to try out, at least until next week when the RC enters
experimental.

> > I can't guarantee a .deb a day at the moment, but if we can get a sarge
> > backport of a recent bzr then I can improve it a lot. Probably including 
> > chroot builds for different distros.
> 
> How big a job is it to backport bzr 0.13 (say) to sarge? I'm currently a
> bit out of touch with bzr development. The requirements on
> http://bazaar-vcs.org/InstallationFaq seem fairly simple. I'll give it a
> try some day soonish, unless someone beats me to it.

I've outlined this in the other email. It's not that hard, there just
needs to be a decision about which way to go.

> I'd say that daily builds (and test run logs), even if the debs aren't
> even distributed, would be a good idea. It gives almost real time
> feedback on what broke, when something breaks.

Yes, I agree, the PQM runs the test before a commit, so they are run,
but doing it in different environments will be useful.

I've just added these to my TODO list for builddeb:
  * Capture log output.
  * Option to pre-pull from the upstream branch.
  * Option to stop the build if the pre-pull doesn't pull anything.

This is starting to turn in to another project, but I have some ideas
that way too, lets see if any code ever comes out of it.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256