[Build-common-hackers] CDBS code repository on line?

[Karl Hegbloom]

On Mon, 2006-04-03 at 23:42 +0200, Peter Eisentraut wrote:
> Karl Hegbloom wrote:
> > Do yous keep a source repository on line under some revision control
> > system?
> 
> No.

Alright.  Maybe I'll toss it off to git for patches.

> > In brief, I'm going to perform some minor adjustments that will make
> > creation of <pkg>-dbg easier and more automatic.  I didn't want a dbg
> > package to have a redundant copy of the documentation installed, and
> > attempted to put a symlink in /usr/share/doc, but the dh_installdocs
> > runs before the dh_links.
> 
> That sounds like an interesting idea.  But it assumes that one dbg 
> package corresponds to exactly one regular package, which is not the 
> common situation.

Hmm, yes, it should be flexible enough for any configuration.  What are
the cases?  Let's see...  There can be one or more binaries in one or
more packages, zero, one or more libraries in zero, one or more packages
which may or may not be consolidated into or associated with a package
of the first type built from the same source... and some packages that
are not written in a compiled language that dh_strip knows how to
produce debugging symbols for the binaries thereof. (ahem)

So, it could be that we want a -dbg package for a shared library set,
and/or for a command binary set, built from the same source... there
could be more than one shared library built from the same source
(FireFox) and/or more than one command binary (Xorg ?).  Sometimes it
will make sense to make one -dbg package for the entire set built by the
source package, other times it will make sense to make -dbg packages
associated with subsets of the shared libraries and/or command binaries
it creates.

Hmmm.  It really doesn't make sense to have two -dbg packages for one
shared library or command binary package, so there's always going to be
zero or one -dbg package for one or more shared library or command
binary packages.  It's possible to make one -dbg package that depends on
more than one shared library, perhaps... or on a shared library and a
command binary package that requires that shared library also and is
built from the same source package...  but it really makes more sense,
to me anyhow, to just say it must be a one-to-one relationship, one -dbg
for the shared library, one for the command binary, and the -dbg must
depend on the package it provides symbols for.

What is "the common case" that you are thinking of?  It's difficult to
obtain a sense of scale or of what's in common without reading the build
system to a lot of packages! (see below)

> > Is there a Wiki for CDBS?  Someone should start a 'CDBS Cookbook'. 
> > It should have a beginners page (think "freshman" wannabe) that
> > explains what you should read first and provide a tour guide in order
> > to fully grok CDBS' .mk files.
> 
> There is a manual.  Is there anything you would like to see added there?

I've seen that... should read it again in case it has been developed
since the first time I did.  I'm just thinking in terms of the freshman
level wannabe MOTU who will need to learn GNU Make, etc...  and then
that even experienced maintainers have not seen every package there ever
was let alone studied them in terms of how what they do could be
abstracted into a general form compatible with CDBS.  They'll need a
guide book and cookbook, so they can find the way around CDBS's (the
best documentation is the source) and find recipes for common "design
pattern" build problem solutions, which should have pointers, perhaps,
to packages where that was necessary.

... along with an explanation of the problems encountered and solutions
found... hence the idea of polling the maintainer crew for pointers into
their own packages, since they know their own territory and rarely does
anyone have time to read the build system for EVERY package.  I don't,
that's for sure, but would like to see the interesting ones.  No search
engine is going to find them for me, so there's got to be a page of
citations and abstracts, and perhaps an archive of those package build
systems for posterity, since after CDBS rules, everyone will port to it,
and that documentation should remain stable.

Hmmm... for each package, diff -u debian/rules ${dh_make_debian_rules} |
diffstat... etc. and try to get a profile showing what's not using
debhelper and of those that are, how customized are the rules?   I'd
rather just poll the maintainer crew, because that grep isn't going to
tell me things about what the packager experienced during the design of
the custom packaging system.  Anything using 'straight' dh_make with
very little customization required is old hat, so no need to waste a lot
of time on them.

-- 
Karl Hegbloom <hegbloom at pdx.edu>
A year in the laboratory often saves an hour at the library.