Expanding on NO_ROOT: Categorizing installed files

Thu Jul 10 16:41:20 UTC 2014

On Thu, Jul 10, 2014 at 09:26:19AM -0700, Sean Fagan wrote:
> On Jul 10, 2014, at 8:35 AM, Brooks Davis <brooks at freebsd.org> wrote:
> 
> > I very much like the functionalty and think it's a good idea.
> 
> It was mostly Xin and Jordan's idea :).  ("Wouldn't it be nice if we could
> use that somehow?  Sean, go do that.")
> 
> >  I don't
> > understand why you didn't use the existing -T/tags= mechanism in
> > install which we're already using for debug info.
> 
> A couple of reasons:  first, because it wasn't clear to me who was using -T,
> and I didn't want to alter the functionality of that; second, because I wasn't clear
> how one would have multiple tags.  (The latter is not a huge deal, I can obviously
> code that up easily enough, and make a comma-separated list in install.)
> 
> I had initially called it "package", btw, and that shows up in some places still.
> "category" seemed like a better name.

I'd prefer we just expand the use of tags.  Thus far a seperator isn't
defined, but : seems as good as any.  It would be worth checking if
NetBSD (where -T came from) uses anything.

> >> diff --git a/Makefile.inc1 b/Makefile.inc1
> >> index c0591b6..b9edd0d 100644
> >> --- a/Makefile.inc1
> >> +++ b/Makefile.inc1
> >> @@ -14,6 +14,7 @@
> >> #	-DNO_KERNELOBJ do not run ${MAKE} obj in ${MAKE} buildkernel
> >> #	-DNO_PORTSUPDATE do not update ports in ${MAKE} update
> >> #	-DNO_ROOT install without using root privilege
> >> +#	-DLOG_META_INFO Log metadata about installed files
> > 
> > I don't see much value in supporting the metadata log in the install as
> > root case.  Is there are reason it's needed?
> 
> I initially only used NO_ROOT.  However, then when I started making packages
> using that, I found out that I really did need to have the install run as root, because
> I could not specify all of the mode bits in the PKGNG manifest, and thus I needed
> tar to pick them up.  (Eventually, admittedly, I did end up using the python tarfile
> module, and so that's an option.  However, getting the right bits in the tarfile module
> in python is a pain, and it's easier to let it set things from the actual filesystem.)
> Further, I didn't assume everyone who wanted to use this would want to do full packaging,
> but might want to instead simply use grep and tar to pick which files.  Or many other
> things.
> 
> So I opted for the most flexible variant, which was to keep NO_ROOT behaving as it did,
> and add another case that used most of the work from NO_ROOT.
> 
> Does that make sense?

Yes.  I'm reluctant to add yet another option to the toplevel make as
that's one more thing to test or break.

Ideally we'd add support for filtering on catagory/tag to libarchive and
do all that stuff there.

Purly FYI, my eventual plan is to generate a METALOG as part of
buildworld/buildkernel so the install* targets just run tar and
dramatically limit root privilage use.

> >> distributekernel distributekernel.debug:
> >> diff --git a/bin/Makefile b/bin/Makefile
> >> index e5052ca..ca218ac 100644
> >> --- a/bin/Makefile
> >> +++ b/bin/Makefile
> >> @@ -1,6 +1,9 @@
> >> #	From: @(#)Makefile	8.1 (Berkeley) 5/31/93
> >> # $FreeBSD$
> >> 
> >> +META_CATEGORY= base
> > 
> > I belive this should be in bin/Makefile.inc which will eliminate the need
> > for .EXPORTVAR.
> 
> I will try that later; thanks.
> 
> >> diff --git a/lib/csu/amd64/Makefile b/lib/csu/amd64/Makefile
> >> index afe7fe6..5616e04 100644
> >> --- a/lib/csu/amd64/Makefile
> >> +++ b/lib/csu/amd64/Makefile
> >> @@ -9,6 +9,9 @@ CFLAGS+=	-I${.CURDIR}/../common \
> >> 		-I${.CURDIR}/../../libc/include
> >> CFLAGS+=	-fno-omit-frame-pointer
> >> 
> >> +META_CATEGORY=	base
> >> +.EXPORTVAR: META_CATEGORY
> >> +
> > 
> > I think the .EXPORTVAR is gratutious here and in the other
> > lib/*/Makefiles.  For that matter, I don't understand why it's needed at
> > all given the presence of META_CATEGORY in lib/Makefile.
> 
> I didn't put it in all of the Makefiles, and the reason for having it in
> the environment was to allow for sub-directories to pick it up; it also
> allows for them to easily over-ride it.  (E.g., for any library in src/lib
> which someone might decide shouldn't really be part of base.)

I think I wasn't clear here.  Given that META_CATEGORY=base should be in
the environment already, I don't see why you need to define it in some
of the library make files.  Thinking about it more, I find my self
wondering if it's a workaround for the failure to use Makefile.inc.

> >> diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile
> >> index dfa450e8..268ce8a 100644
> >> --- a/share/man/man9/Makefile
> >> +++ b/share/man/man9/Makefile
> >> @@ -1,5 +1,8 @@
> >> # $FreeBSD$
> >> 
> >> +META_CATEGORY=	kernel
> > 
> > I can see some loging in this, but it seems like a somewhat odd choice.
> 
> Odd choice how?

While section 9 manpages document the kernel, I don't see them as part of
it.

> >> diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
> >> index cd11e3a..ea50d33 100644
> >> --- a/sys/conf/kmod.mk
> >> +++ b/sys/conf/kmod.mk
> >> @@ -68,6 +68,10 @@ KMODLOAD?=	/sbin/kldload
> >> KMODUNLOAD?=	/sbin/kldunload
> >> OBJCOPY?=	objcopy
> >> 
> >> +.if defined(META_CATEGORY)
> >> +META_LOG_SYMBOLS=	-P ${META_CATEGORY}:dev
> > 
> > There seem to be more spellings of META_LOG_SYMBOLS than necessicary
> > (_META_INFO).
> 
> I'm not sure what you mean?

You use a variety of variables used to hold "" or "-P
${META_CATEGORY}..." in different Makefiles.  It seems like they should
be the same where possible.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 311 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140710/943b429d/attachment.sig>