Re: Fwd: DragonFly ISO release build failure

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:    It occurs to me that having a pre-install upgrade target is not 
:    sufficient, especially when one is building a release where the
:    install target is not "/".
:
:    I'm thinking for this case we should add an option to install to
:    allow an alternative group number to be specified if the group name
:    does not exist.  e.g.:
:
:    install -s -o root -G authpf:63 ...
:
:    I am going to test that out as a solution.
:
:						-Matt

    Well, nix that idea.  After looking at the build system I don't think
    it's workable (or clean).

    We have another issue, and that is when building a release we want to
    use the numeric id's based on /usr/src/etc/group and 
    /usr/src/etc/master.passwd rather then the uid's and gid's of the
    current system.

    It might be better to add an option to install that specifies the 
    location of the group or password file rather then trying to extend the
    uid / gid specification.  We could then use user and group names directly
    even if the current system does not have them.

    This would work both for make release, buildworld, *and* manual builds.

    The options would be something like:

    -L basedir_for_uid_gid_lookups	(defaults to "/")

    e.g.  '-L /usr/src' would cause install to use /usr/src/etc/{group,passwd}.

    What remains then is whether we should support sysops specifying different
    group and user numbers for the 'standard' groups and users that the
    build system expects.  In that case an installworld would have to use 
    the system's password and group file (and require a pre-install upgrade
    target), but a release build would still want to use /usr/src.  It might
    just be easier to set the numbers in stone and require that the uid's 
    and gid's in /usr/src/etc/Makefile match the ones in the current system.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>