> > Have you seen "pio" the Package Installation Observer in the Hints?
> [...]
> >
> > [...] do a "make install", et seq., and I'll record what gets installed
> > [...] handy things are then possible, like searching through them to
> > see which package a particular file belongs to.
> >
>
>
> Sometimes o/c a package cmmi skips creation/&c of a particular
> '(path,type,contents,permissions,ownerships,...)' item, because it sees
> that such an item already exists: the latter may have come from
> an earlier version of the package, or from a different package, or
> somewhere else.
>
>
> Does pio list that the current cmmi package (joint-)owns that item ?
>
>
> akh
>
In the first place, I must run pio at the appropriate times, _generally_ in my
build scripts just before make install, or sometime before make, depending on
how the package builds itself, and again _generally_ after the following
configuration bits in the book are done. If some of those I deem idiosyncratic
to a particular system, they go into a different part of my build script.
In general characteristics, pio is a "time stamper" that compares "snapshots"
of given branches of the FS, ignore others (i.e. /var/log typically) at two
different times, then constructs a script that will remove whatever popped up.
It really doesn't "care" or impose meaning on what just happened. Perhaps I
was planning to visit a dodgy website or use a dodgy javascript?
Other functionality is added on. For example, immediately after I run it the
second time to get the removal script, I run its "backup" function that
tarballs those pristine files.
As I already said, at this time I can also *tell it* what the package's
dependencies were, just so it will warn me if I try to remove any of them, but
with my OK it will do it anyhow. It never deletes a backup tarball! I may be
about to replace that dependency. pio can't know if it will "work", of course,
but when I removed it I had the option of removing that removal script. I
wouldn't in such a case. Then I install the replacement normally. If it's a
cockup upon testing, I can remove the replacement and restore the original from
the backup, none the worse for te attempt.
Besides the normal "B depends on A", if A's only function is to support B, I
can *tell* pio it goes the other way too, "A supports B". That way if I decide
to dump B I can track down everything installed for it and remove them too.
All these things are just well-formed comments in the removal scripts that can
be grepped. But it's up to me to use them or not.
To reiterate, pio's "attitude" is _NOT_ "I'll do all the package management for
you", but "I'll give you some basic tools to assit you doing package
management." I like that, because as your question suggests, sometimes it's
not such a simple task. And sometimes we have to think about how to control it
first. pio won't protect me from myself or my own misuse, but I really don't
want it to try!
[10:01 ~]# pio --help
Usage:
pio PKG
pio command
[--cd] [--deps] [--help] [--profile] [--version]
pio command [argument]
[--cwd [...]] [--ls [PKG*]] [--lsbak [PKG*]] [--dirs [PKG*]]
pio command argument
[--edit PKG] [--remove PKG] [--backup PKG] [--restore PKG]
[--check PKG] [--files PKG] [--files0 PKG] [--list PKG]
[--xcheck PKG] [--find FILENAME]
pio PKG command argument
[PKG --requires PKG2] [PKG --uses PKG2] [PKG --supports PKG2]
pio [PKG] --lib [LIBNAME]
pio [PKG] [--watch DIR1 DIR2 ...] [--ignore DIR1 DIR2 ...]
i.e.
PKG observe installation start/finish of PKG
--backup PKG create a backup of the files in PKG
--cd change the current directory to /usr/local/pio
--check PKG check current files against backup
--cwd [...] execute with arguments given in [...], but create all
working files in ./ (only works as first option)
--deps show all dependencies and usages
--dirs [PKG] show the defaults for --watch and --ignore or the
values used for the (current) installation of PKG
--edit PKG edit PKG's script preserving the file's timestamp
--files PKG list the files in PKG
--files0 PKG list the files in PKG with null-terminated names
--find FILENAME tell which PKG installed files matching FILENAME
--help display this help and exit
--ignore DIRn paths excluded from being watched during installation
--lib [LIBNAME] tell which programs use libraries matching LIBNAME
--list PKG list information about the files in PKG
--ls [PKG] list all de-installation scripts matching PKG*
--lsbak [PKG] list all backups matching PKG*
--profile print definitions required for option --cd and for a
variable containing /usr/local/pio
--remove PKG call the de-installation script for PKG
--requires PKG2 note the dependency on PKG2
--restore PKG restore files from backup PKG
--supports PKG2 note the exclusive use by PKG2
--uses PKG2 note the advantage because of PKG2
--version output version information and exit
--watch DIRn paths to be watched during installation
--xcheck PKG cross-check contents of PKG against all other
(executable) de-installation scripts to find out
whether a file has been installed more than once
[10:02 ~]#
--
Paul Rogers
[email protected]
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
