Subject: Re: permissions problems in METALOG file
To: David Laight <firstname.lastname@example.org>
From: Luke Mewburn <email@example.com>
Date: 05/19/2002 20:52:54
On Thu, May 16, 2002 at 02:03:25PM +0000, David Laight wrote:
| I've just updated my 'current' system to current 'current'.....
| When copying the built files from $DESTDIR to / using the info
| from METALOG ('cos I did an UNPRIVED build) I found the
| following inconsistencies in the METALOG file.
| There are a several programs that are installed with multiple
| names. Traditionally these have been hard linked together,
| indeed the previous METALOG file had type=hlink entries for these files.
| However these entries (today) are type=file.
| (some have been replaced by symlinks)
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).
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). If you're using
the METALOG for any other purpose, you need to understand its
| This wouldn't matter too much (apart from the extra disk space)
| except that for those that are normally suid/sgid the permissions
| on the subsequent lines are just 0555.
This doesn't pose a problem with the way that pax's specfile support
works, as long as the file that the entry is linked to appears *first*
in the METALOG. This is the case, unless you sort the METALOG file
(which is what maketars was doing before rev 1.23)
| 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, at least in as much as the building of
tar files by distrib/sets/maketars. 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).
| 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
Yup, see PR [toolchain/16207]...
Luke Mewburn <firstname.lastname@example.org> http://www.wasabisystems.com
Luke Mewburn <email@example.com> http://www.netbsd.org
Wasabi Systems - NetBSD hackers for hire
NetBSD - the world's most portable UNIX-like operating system