[EMAIL PROTECTED] wrote:
> Then you need to re-read the man page for tar. That would be
> horrendous default behavior in *nix. This isn't DOS... where the user ==
> the sysadmin :)
In the book "UNIX System Administration", by David Fiedler and Bruce
Hunter, it says this:
tar's syntax is simple enough, but _where_ you start your tar copy is
critical. If you start from root, the file paths on the archive also
start at root. Thus, the file names will be fully qualified [...] If
you start at the base of the file structure [...] the archive also
starts there [...]
Not wanting just to take the UNIX book's word for it, I tried it under
Linux. GNU tar created the archives just right, but when extracting
the file with full pathnames in it, it said:
tar: Removing leading '/' from member names
(!)
UNIX tar in all its antiquity would never fathom to behave in such a
fashion. This is entirely a new thing to me, and appears to be
specific to GNU tar.
> I note that GNU tar's use of P is different than SunOS's use of the P
> option. It is not clear to me that an absolute pathname interpretation
> mode is even available on SunOS. I don't have any other Unices around to
> check this on.
I had to go look at the man page to see what P did; what P does is
revert to UNIX tar behavior, truly speaking. Thus, given an archive
created by:
tar cvf - /usr/local/* | gzip -c - > file.tar.gz
...and unpacked at ~user, you will get to different things depending
on whether you use GNU tar or UNIX tar. UNIX tar would give you:
/usr/local/x
/usr/local/y
...
but GNU tar would give you:
~user/usr/local/x
~user/usr/local/y
...
Not entirely a pleasant thought - but almost no one who knows anything
uses absolute paths in tar anyway (probably what the GNU people were
thinking...)
Also, tar z is (or was) also specific to GNU tar; UNIX tar never had a
z option.
> "tar xzvf" is burned into my brain as the lowest common denominator for
> installing software in Linux.
Ah, but it's NOT the lowest common denominator for UNIX: tar z is
invalid.
> I find it hard to imagine that people who
> haven't learned that will have any desire to extract files from packages
> into a subdirectory for any reason. But if you think they will,
> "apkg -x" will get no complaint from me.
Probably true. I mostly use that myself for fixing root.lrp when it
won't boot, or for updating system libraries in /lib.
> You don't need the files themselves to do that. If you want that
> capability, then just process the output of
> tar tzvf mypkg.lrp
> relative to the root directory to identify any files that are about to get
> overwritten.
Sharp thinking.
> But beware.. some packages have been designed to behave just that way, to
> be loaded once, backup etc.lrp or somesuch, and then remove the fixer
> package. At least query the user before preventing the package from
> loading at all.
Never heard of such, nor seen such. All the packages I've seen are
either "add-on" (ie, straight out and out tar.gz files with no
supporting LRP files in /var/lib/lrpkg) or are standard packages.
> Because for 99.99% of the time, you just want files in the package to land
> at their destination. Why satisfy 0.01% of the users by changing the
> default mode of operation?
However, the possibility of conflicting packages arises. I found
(much to my dismay!) that the ppp.lrp and pppd.lrp packages conflict -
ppp is the client package, and pppd adds the server to it. OUCH!
Checking for conflicts will help prevent corrupting the packages.
> > You seem to be refering to the step of creating a *.lrp in /tmp.
> > Oxygen creates a LOT of files in /tmp during package creation; I just
> > use the following script snippet and I only have one "file" to delete
> > -- and I don't even have to explicitly delete it either:
> >
> > WORK=/tmp/$$
> > trap 'rm -rf $WORK' 0 2 5 15
>
> That is neat.
Actually, I just noticed: I got the snippet wrong; it actually goes
like this:
WORK=/tmp/$$ && mkdir -p $WORK
trap 'rm -rf $WORK' 0 2 5 15
...usage becomes...
cp MYWORKFILE $WORK
....et al.
> If I can trust apkg not to screw up, then yes. By invoking that
> commandline, I _did_ just say that was what I wanted to do... so stop only
> if the operation is guaranteed to fail or is going to make an
> irreversible change.
Hmmm....
apkg -b X
will automatically back up a package, but it doesn't check for space.
The space checking code and prompting is all another program (bpkg) so
I dunno... perhaps I need a program to check if file A will fit into
space B...
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
