Re: Setlist maintenance

[christos%astron.com@localhost (Christos Zoulas)]

In article <20121212143721.GA10560%panix.com@localhost>,
Thor Lancelot Simon  <tls%panix.com@localhost> wrote:

>I do not think it is a good idea to auto-generate set lists.  I think
>there is real value to forcing the developer to actually think about
>what files he or she is causing to appear in the built system.

I think humans make bad robots. Recently I had to fix a whole bunch
of mistakes in the set lists:

- shared libraries declared in the wrong sets
- obsolete files put in the wrong file
- entries were not sorted
- inconsistencies in the way documentation lists are declared
- duplicated information

I am all for a tool that helps producing consistent and correct sets.

>Unlike many other package-building systems, NetBSD's setlists really
>constrain the built system so that it contains only what is in the
>lists.  That is a good thing.  When I was building NetBSD based embedded
>systems for a living, this frequently caught cases where developers
>(ours, not NetBSD's -- but myself included) screwed up their Makefiles
>and put all kinds of random crap into the system by accident.

I agree with that, but the tool would help in that case too. It would
show what changes will happen to the lists. It is up to the developer
to accept the file additions or fix the Makefiles not to install extra
crap. We can always check the history to find out why the extra files
were added and fix them.

>We were migrating away from a legacy build system that ran the native
>builds of another BSD flavor and all sorts of add-on packages, let
>them install whatever they wanted to, then tried to _delete_ anything
>anyone noticed was extra.  I can't tell you what a disaster that was.
>
>NetBSD's setlists are also very useful for building alternate, smaller
>versions of the system -- you can build a set that is actually a small
>subset of "base" or "etc".  I think this isn't widely known, but it is
>a really neat trick (Matt Thomas pointed it out to me).  I worry that
>automatically generated setlists would bring with them unexpected
>dependencies between components which would make this harder to do, since
>we would go from actually thinking about everything any component causes
>to be in the built system to just naively accepting whatever the first
>attempt at the Makefiles happens to put there -- missing opportunities
>to pare things down or adjust them so they work better without creating
>later incompatibilities.
>
>So, I like Alistair's tool but I strongly urge that it not be used by
>default to generate the setlists for the sets shipped as NetBSD.

I think a different use of the tool is to use it to once sync what our
lists should be with the ones produced by the tool, and then produce
a daily diff of what the tool thinks that the lists should be and what
they actually are, and then make sure that the diffs are kept to a minimum
by applying corrections on either side to maintain the desired result.

christos