Re: Sets, subsets, syspkgs, and MK*

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

> > My point is to realize that most USE_* variables change signature globally.
> > USE_YP even changes libc signature.
> 
> Ah, yes indeed _some_ USE_* variables do currently change the
> distribution contents.  I guess we disagree on the relatively quantity
> only.  I would say that "most" USE_* variables do not change the
> distributions contents.  Only three out of 10 or 11 of them do so.  ;-)

0 exception and >0 exceptions is a big difference. :)

> Some (at least one, maybe two) are also poorly named and don't seem to
> belong with the ones we're discussing, so that doesn't help clarify
> anything either.
> 
> As for the "signature" of the distribution, well of course, that's the
> whole point of the USE_* variables -- they necessarily change how
> various files look on the inside, including libc.  That's why they must
> be set to one fixed default for all official distributions.  You can't
> go changing any of them, any more than you can change any of the
> 
> Perhaps this is where I've been confused.  By "contents" I thought you
> meant the list of files in the distribution, not the content of the
> files themselves (or both).

I'm still sorting out ideas.  We've only started sharing views.  I hope we'll
have a well-defined set of concepts and terminologies in the end.  (Note I'm
not English-native.  I need much help of you here.)

> BTW, have you considered this comment in share/bsd.own.mk?
> 
> # USE_* options which default to "no" and will be forced to "no" if their
> # corresponding MK* variable is set to "no".
> 
> I suspect if USE_INET6, USE_KERBEROS, and USE_YP were controlled in a
> similar way to USE_SKEY (i.e. with the MKINET6, MKKERBEROS, and MKYP
> settings forcing the corresponding USE_* value) then their use in
> creation of the sets could be eliminated and only the MK* variables
> would be used in distrib/sets/sets.subr to control the list of files in
> a given distribution.

I've not investigated all those vars.  I think the basic rule is that bsd.own.mk
is the place to sanitize those vars given by users.

Some vars have dependencies, some have conflictions, and some only change
signatures of subsets.  Pretty much same seen in any packaging systems.
Difference is we have more control of our own basesystems.

> That's a good question, but of course I don't have a real answer.
> 
> I have distributed binary patches privately though, to my client sites,
> using "build.sh -Uu" again after applying source fixes and then
> selecting those files noted as freshly installed in the $DESTDIR/METALOG
> file (my wrapper script for build.sh adds a comment to the end of the
> METALOG file after every run to make selecting newly installed files
> much easier).  I.e. I would do a full build with virgin sources, then
> apply the patches and update the build, and then archive up the files
> (re)installed by the update.  I didn't bother to try to ship only the
> necessary binary deltas (i.e. compress the patch), but assuming one has
> tools to create and apply such binary deltas on the target systems then
> one could also do that level of optimisation as well.  One could also
> package binary patches up in pkg_install format, but I didn't go that
> far either.

You seem to be the only *serious* NetBSD user in this thread. :)

I think your use of METALOG (check only updated & installed files) makes much
sense.

I feel unnecessarily rebuit files & installed files annoying.  If we compare
DESTDIRs by content, timestamps don't really matter... but still confusing.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635