On Fri, 6 Apr 2001, David Douthitt wrote:
> I'm surprised no one is understanding this complaint; I think I
> understand it perfectly. It has occurred to me also.
Some good points are made below, but the temporary copy still seems
unnecessary.
> [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.
Most people... don't unpack .lrp files by any method other than the
automatic one arising from the LRPKG option in syslinux.cfg.
> > 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,
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 :)
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.
[... valid methods of adding files to tarballs omitted ...]
> > 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.
"tar xzvf" is burned into my brain as the lowest common denominator for
installing software in Linux. 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.
> > 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 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.
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.
> > 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?
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?
> > 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
That is neat.
>
> > 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,
? output of command is mypkg.lrp ... if one already exists, I would like
to be given an opportunity to avoid overwriting it. However, that is not
as important as avoiding writing to the filesystem if there will not be
enough space on the filesystem to complete the write.
> 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?
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.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Work:<[EMAIL PROTECTED]> Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
