I'm surprised no one is understanding this complaint; I think I
understand it perfectly. It has occurred to me also.
[EMAIL PROTECTED] wrote:
>
> On Thu, 5 Apr 2001, S.C.Best wrote:
> > I'd be ill advised to extract a new dnscache.lrp without
> > carefully controlling where it untar's. The defaults would overwrite
> > what's my system was using.
>
> What default? The only "default" is the current directory you are in when
> you untar the lrp file. Since I cannot imagine doing that into "/" on a
> non-LRP system, you are mystifying me. Are you referring to wanting to
> use lrpkg (which automatically cds to "/" temporarily during the install)
> on a running LRP system to extract the package without interfering with
> the system? Why not just use tar/ctar yourself instead of lrpkg then?
Most people won't think of using tar/gzip to unravel a package, and
perhaps don't know how, or where, or anything of the sort. This is
why the apkg -x option was created - but it only unpacks a package in
the CURRENT directory.
> Is there something in your concern about absolute paths? If so, I know of
> no requirement to use absolute paths, and tar by default ignores any
> leading "/" that happens to be present in the archived filenames.
My understanding is that tar takes your pathname as specified when you
pack. For example,
tar cvf file.tar .
...creates files with names like "./myfile1" "./myfile2" etc.
tar cvf file.tar *
...creates files with names like "myfile1" "myfile2" etc.
tar cvf file /pub/home/mydir
...creates files with names like "/pub/home/mydir/myfile1"
"/pub/home/mydir/myfile2"
> The copying seems an unnecessary use of disk space and time. If you want
> it in a separate subdirectory, then by all means put it there when you
> want it there.
Most people wouldn't know how to go about that - even the tar options
are rather obtuse and strange.
> There might even be an advantage to adding commandline
> options to lrpkg to do that, though tar/ctar seems quite sufficient.
ctar is unusual and unique to LRP.... However, apkg has such an option
as you describe.
> But
> I just cannot see the advantage of all that extra copying and deleting in
> the normal course of operation.
>
> What would it accomplish?
It would allow the checking of the packaged archive against the
running system; any conflicting files would be flagged and the loading
of the package prevented.
> You expressed concern over working files
> getting replaced... but having lrpkg untar them to a temporary location
> and then cp/mv them automatically would be no safer from your fingers
> point of view. Would you require that lrpkg be run in two steps?
Why not?
> d) only one file needs to be cleaned up after the copying operation is
> complete.
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
> e) I find that particular step fairly error prone... I have to pay close
> attention, and I still don't really know if I am doing the right thing
> unless I trust that I knew what was on that disk before I started the
> backup anyway. The Macintosh technique of precalculating whether there is
> going to be enough disk space to complete a copy operation automatically
> BEFORE it begins the copy, and only prompting whether I want to overwrite
> an existing file _if one exists_ makes a lot more sense to me than adding
> more predictable pauses for error-prone user inspection.
I'm not sure about the "overwrite" business, but the apkg -s method
(or bpkg method) used in Oxygen is thus: space is checked on disk, and
if there isn't enough the attempt to back up is rejected; if there IS
space, then the following items are noted and reported to the user:
* Free space on disk
* Available space on disk (free space + pre-existing archive, if any)
* New package (or not)
Then the user is queried, and can reject the backup if desired.
Would it be better to backup new packages automatically?
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
