xinstall: Add metalog contents reference link type

[emaste]

Summary

Allow install to reference the source file using the mtree(5) contents= tag rather than creating a filesystem object. This is conceptually similar to creating a (symbolic or hard) link, so I implemented it as an additional link type.

Posted for comment on the approach of implementing this as a link type.

Still todo:

• support for absolute and relative contents= references
• tests
• digest

[markj]

Do you have a patch for share/mk which I can use to test this?

The patch doesn't apply to the latest main btw.

usr.bin/xinstall/xinstall.c

166

Make this a pure function, so that callers can write something like dolink = parse_l(p, dolink);?

Hmm, I guess it doesn't matter too much, this function is only called once.

695

Missing newline.

[emaste]

usr.bin/xinstall/xinstall.c

166

That's what I did at first, before discovering that dolink is a global. I mainly moved this out because main was getting rather long and indented.

[emaste]

• improve man page
• move (and rename) parse_l
• add digest
• start adding test suite

[emaste]

Hrm, on 2nd thought -l c is not as obvious as I at first thought. We use the existing -l modes in the build already, via INSTALL_LINK, INSTALL_SYMLINK, INSTALL_RSYMLINK.

There are actually two separate requirements here:

• disable all filesystem object creation (not just file copies)
• write file contents= to metalog

This patch handles the 2nd, but not the first. I could add another flag e.g. -n to handle the first item, then metalog-only installworld could be achieved via e.g. make INSTALL="install -n -l c" (and the -l ? flag from e.g. INSTALL_SYMLINK would override the -l c).

Or, just introduce a new flag that does both.

[emaste]

Aside from fixing compatibility with symlink/hard link creation we'll also need to address certctl, which currently has ${METALOG_INSTALLFLAGS} passed to it in installworld.

[brooks]

Seems reasonable. A couple comments about things that were already here.

usr.bin/xinstall/xinstall.c

1446

Should '=' be in this list?

1454–1460

I wonder why this isn't PATH_MAX * 4 + 1 and statically allocated?

[markj]

In D57411#1315567, @emaste wrote:

Aside from fixing compatibility with symlink/hard link creation we'll also need to address certctl, which currently has ${METALOG_INSTALLFLAGS} passed to it in installworld.

Does this suggest we should try to move metalog entry handling to libutil or similar?

In D57411#1315534, @emaste wrote:

Hrm, on 2nd thought -l c is not as obvious as I at first thought. We use the existing -l modes in the build already, via INSTALL_LINK, INSTALL_SYMLINK, INSTALL_RSYMLINK.

There are actually two separate requirements here:

• disable all filesystem object creation (not just file copies)
• write file contents= to metalog

This patch handles the 2nd, but not the first. I could add another flag e.g. -n to handle the first item, then metalog-only installworld could be achieved via e.g. make INSTALL="install -n -l c" (and the -l ? flag from e.g. INSTALL_SYMLINK would override the -l c).

Or, just introduce a new flag that does both.

I think the latter (just add -n) makes more sense: at first it seems like this is really just a new link mode, but it's not, the new functionality only makes sense when you've configured a metalog, so it's kind of orthogonal to the other -l flags.