Subject: Build strategy
To: Martti Kuparinen <martti.kuparinen@iki.fi>
From: Nicola Bolla <nicola.bolla@erogasmet.it>
List: tech-pkg
Date: 05/07/2004 08:33:31
Hi Martti, I know you are used to build all your applications using
pkgsrc on the Linux/Slackware platform. I'm trying to do the same using
Linux/debian. The task is emerging to be quite challenging for me (not
having deep technical skills), although Thomas Klausner and others (you
too) are helping me quite a lot. I would like to learn from your
experience: in particular, I was disappointed to discover that some of
the compiling errors I had, magically disappeared as soon as I decided
to restart from zero the whole process, from a clean situation. I think
that is due to the fact that while I am building my workstation
environment, package after package, day after day, the pkgsrc tree keep
on changing, hour after hour, under the effect of the commit activity of
the maintainers. So, it happens that while I am building a new package,
maybe that some packages (already installed) on which the new package
depends are out of sync, compared with the current release/version in
pkgsrc. I don't want that this situation could cause errors in the
building of new packages, otherwise I louse time and I risk (and this is
bad) to make louse the time of the kind people of the list who are
trying to help me.

Which is, in your experience, the best strategy to manage this problem?
I am wondering which of the following alternatives is the best (not
being sure that better ones may exist):

1) before building any new package/metapackage do the following:
- anoncvs the pkgsrc
- rebuild /usr/pkgsrc/bootstrap, to be sure that "bmake and friends" are
up to date
- find out which packages are old with "lintpkgsrc -i" 
- do a "bmake update" for each of them
- start building the new package

What worries me is the fact that if package "c" depends on packages "a"
and "b", and if both "a" and "b" have to be updated, I risk to rebuild
"c" twice, first doing "bmake update" on "a" and than doing "bmake
update" on "b".

2) like the first 3 steps of 1) and than:
- pkg_delete all out of date packages and write down the names of the
"leaves" important packages that are listed to be deleted beeing
dependent on the package targeted for deletion
- "pkg_delete -r" all out of date packages
- "bmake install" all the important packages been deleted
- start building the new package

3) like the first 3 steps of 1) and than:
- starting from the more out of date deep packages in the dependency
tree, do:
      cd /usr/pkgsrc/<category>/<package foo>
      bmake && pkg_delete -f <installed out of date package foo> &&
bmake install clean clean-depends
- start building the new package

This idea came to me from the "pkg_version -c" FreeBSD output and from
the "Absolute BSD" book of Michael Lucas. This strategy seems to be the
most efficient one because not all the dependent packages are rebuild:
only those out of date. This seems to be a strategy similar of
"portupgrade -rRa" in FreeBSD. The problem is that, if the list of out
of date packages produced by "lintpkgsrc -i" is very long, it can be
very difficult for me to find out the right order with which to process
the packages, from the "more dependent" to the "less dependent". There
is also another doubt: it's not clear to me if, in the case "c" depends
on "b" but ONLY "b" is out of date, it is safe enough to rebuild only
"b", avoiding to rebuild "c".

Which is the best strategy: 1? 2? 3? ...?

Another question. I noticed that for the Linux platform there are
already built on the pkgsrc ftp server a lot of packages, ready to be
installed via "pkg_add ftp://....../<package>". But....a lot of packages
I am interested in are not available (lyx, gnome2.6, mc, ...).: what
does it mean? That the not available packages are "broken" for the Linux
platform? If this is the case, should be more convenient for me to stop
trying building packages from source and wait until the desired package
is available as a binary package for the Linux/debian platform.

Whow ... what a long post .... but, you know, I decided to stop
mass-building packages until I define a clear and solid strategy.

Any comments will be greatly appreciated.


-- Nicola