On Sun, May 19, 2002 at 08:52:54PM +1000, Luke Mewburn wrote:
> On Thu, May 16, 2002 at 02:03:25PM +0000, David Laight wrote:
>
>   | There are a several programs that are installed with multiple
>   | names.  Traditionally these have been hard linked together,
>   | However these entries (today) are type=file.
> 
> If you extract the .tgz files built by "make release" on -current,
> this is not a problem.  This problem is also described in [toolchain/16207],
> and I fixed this problem (in the tar file generation at least) in rev 1.23
> of maketars (on 2002/04/13).

ok - that is a fix to the problem caused by the METALOG getting sorted
so that the entry for the link came before the entry for the file.

> The METALOG code is primarily designed to be used to build UNPRIVED
> builds into a DESTDIR, and build correct distribution tar files from
> the contents of the DESTDIR and the METALOG file.  It currently does
> that (unless there's some other bug lurking there).

I've not spotted one that stops that working, OTOH I'm not trying to
build distribution tapes.

> 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.

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?


> 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)

>   | The following are definitely affected:
>   | 
>   |     at		atq, atrm, batch
>   |     dump_lfs	rdump_lfs
>   |     chpass	chfn, chsh
>   |     passwd	yppasswd
>   |     systat	sysstat
>   |     dump	rdump
>   |     cksum	sum, md[2-4], sha1, rmd160

Only systat/sysstat sufferred from the sorted METALOG...
The rest are (probably) the only suid/sgin files that have links.

I did some grovelling and found that xinstall had been fiddled
with severel times wrt these entries for links.  The last version
retrieves the mode of the source file then masks it with 0777.
Thus the links have the correct permissions unless they are
suid/sgid (the suid bits aren't set in DESTDIR if UNPRIVED).
I'm not sure there is actually a problem in applying the
suid/sgid bits?
However [r]dump[_lfs] does need to be sgid tty (not wheel)

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 :-)

	David

-- 
David Laight: david@l8s.co.uk