On Sun, May 19, 2002 at 08:01:04PM +0100, David Laight wrote:
  | > If you're using the METALOG for any other purpose,
  | > you need to understand its constraints.
  | 
  | What I'm trying to do (and the information is almost right) is
  | to use the METALOG to work out which files need copying from
  | $DESTDIR into my live system after a successful UNPRIVED update build.  
  | Partly this is paranio about running as few things as 'root' as
  | possible, and partly about ensuring the build completes before
  | overwriting any files.
  | On the whole it doesn't seem an unreasonable use of the METLOG data.

As I said earlier, the METALOG support was added for a specific
purpose, and if your using it for any other purpose, you must
understand its constraints.  If you can use it for other purposes
within the constraints of its existing purpose, then that's good for
you.


  | It also wouldn't be unreasonable to supply it to mtree to validate
  | the permissions of an installed system
  | 
  | >   | Depending on how the copy from $DESTDIR to / is done, either the
  | >   | multiple copies of the file have different permissions, or all
  | >   | the copies of the file have the same permissions - probably that
  | >   | of the last entry - which are wrong.
  | >   | 
  | >   | I don't know what pax does, but my script detected this :-)
  | > 
  | > pax should do the right thing,
  | Ok, if two files that are hard linked together both appear in
  | the METALOG file, pax copies them as linked files and applies the
  | permissions of the first entry - this could be considered a bug :-)
  | (Certainly it would be resonable to emit a warning about inconsistent
  | permissions, maybe it should split the hard link?)
  | 
  | Did you barf at the thought of modifying pax to add the hlink= entry 
  | directly to its internal list of the files to copy (I guess it must
  | generate such a list to detect hard linked files), or was it just
  | too hard?

Yes, it was too hard.  There were too many corner cases to consider,
and every time I had licked one, another reared its head.  It was
going to require a significant rewrite of the way that pax gets its
files from a METALOG, whereas currently the code fits in relatively
easily.  I had written a chunk of that, along with rewriting bits of
mtree(8) and makefs(8) (since all three use the mtree specfile parser
from mtree(8)), but I kept running in to problems.   Part of the issue
was the situation where you didn't have all the hard-linked versions
of a file listed in the specfile (or vice versa), and keeping track of
that became a nightmare.



  | > I need to take a closer looker if
  | > using pax to copy directly from the DESTDIR (with the METALOG) has the
  | > same issue -- it shouldn't but I haven't checked (yet).
  | 
  | pax should work if you have an entire METALOG, however if you only
  | have the records generated by an update build then you have records
  | for the hard links, but not for the file (unless it was rebuilt).
  | (see toolchain/16885)

That is not a supported use of METALOG.  Your METALOG must contain
appropriate entries, and in the case of hard links, that currently
means listing the entry that it's linked to

If you use something other than the mtree specfile parser (present in
pax, mtree, makefs, ...) to apply the METALOG contents, then you may
be bitten by certain situations which the parsers has been modified to
handle correctly.


  | However [r]dump[_lfs] does need to be sgid tty (not wheel)

dump and rdump are setgid tty after extraction of base.tgz that was
built UNPRIVED...


  | I've also wondered whether install could just record where the
  | file was (in the object tree) rather than actually copying it.
  | That would take the METALOG one stage nearer a SVR4 package
  | prototype file :-)

You'd be better off overriding make(1)'s INSTALL in that case.


At this time, I see little "win" in trying to ensure that METALOG can
be used for all sorts of uses other than those used by the UNPRIVED
build system.  If you use it for other purposes and it works, "good",
but otherwise, we don't have the time nor resources to support you.