Removing directories/files in RPM erase

[Hajducko, Steven]

So what's the best practice for removing directories that your RPM owns that contain files that the RPM doesn't know about?

For instance, I've got an rpm that creates several directories and installs a utility. When I start the tool and it's clients, it starts creating files in one of the directories that the RPM owns ( ssl certs, logs, etc ).

However, when I remove the RPM, it doesn't remove the directories because they aren't empty. Should I setup a post uninstall to see if this is the last instance of the package and if it is, manually remove those directories?

Suggestions welcome.

.....................................................................
Steven Hajducko
Systems Engineer, Systems Integration
w: 818.597.6443 m: 805.377.9074


This email may contain confidential and privileged material for
the sole use of the intended recipient. Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient please contact the sender and delete all copies.

[devzero2000]

In this case i do as you suggest.

Best Regards

Post by Hajducko, Steven
So what's the best practice for removing directories that your RPM owns
that contain files that the RPM doesn't know about?
For instance, I've got an rpm that creates several directories and installs
a utility. When I start the tool and it's clients, it starts creating files
in one of the directories that the RPM owns ( ssl certs, logs, etc ).
However, when I remove the RPM, it doesn't remove the directories because
they aren't empty. Should I setup a post uninstall to see if this is the
last instance of the package and if it is, manually remove those
directories?
Suggestions welcome.
.....................................................................
*Steven Hajducko*
Systems Engineer, Systems Integration
w: 818.597.6443 m: 805.377.9074
This email may contain confidential and privileged material for
the sole use of the intended recipient. Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient please contact the sender and delete all copies.
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Tim Mooney]

Post by Hajducko, Steven
However, when I remove the RPM, it doesn't remove the directories because
they aren't empty. Should I setup a post uninstall to see if this is the
last instance of the package and if it is, manually remove those
directories?

Look up the %ghost attribute (?, token?, I'm not sure what it should be
classified as) and see if that does what you need.

Tim

[Jeff Johnson]

Post by Tim Mooney

Post by Hajducko, Steven
However, when I remove the RPM, it doesn't remove the directories because
they aren't empty. Should I setup a post uninstall to see if this is the
last instance of the package and if it is, manually remove those
directories?

Look up the %ghost attribute (?, token?, I'm not sure what it should be
classified as) and see if that does what you need.

%ghost won't solve removing nonempty directories. The %ghost directive,
with its mysterious name, claims ownership for a package of a pre-
existing path. If the
path happens to be a directory, the erase behavior will be identical to
that when the directory is explicitly part of a package.

On erase, rpm runs rmdir(2) on "owned" (i.e. directories that are
explcitly
part of a package) directories. rmdir(2) will fail with ENOTEMPTY
if there are files within the directory. That behavior is (imho)
exactly what one wishes: rpm
already removes files in reverse order, i.e. members of the directory
before parent directory,
so any remaining files are from other packages (which will eventually
succeed with rmdir(2)),
or from side effects (in which case the unknown files should not be
touched).

If the directory contents are created outside of rpm, then its up to
something
other than rpm to manage the directory contents.

If the directory contents are being created by %post scripts, then the
additionally created
files should be removed in %preun for symmetry.

If the directory contents are within other packages you need pin down
which package
should "own" the directory, and arrange through dependencies for that
package to be installed
first (and removed last if you have erasure ordering). The "best
effort" rmdir(2) will
eventually succeed when all other contents are removed. The number of
files
within the directory works as a defacto reference count, the only
difference from
a true reference count is that a rmdir(2) is attempted, but silently/
harmlessly fails.

Establishing ownership of a directory in packaging, particularly for
some public path in which, say, modules
are installed, can be quite complicated. Putting the specific
directory path in its own package, or in
a directory path skeleton package like filesystem, or adding a
Requires: /path/to/directory (or other
ordering hint no matter how expressed) may help establish which
package is responsible for
removing a given directory.

73 de Jeff

[Tim Mooney]

Post by Jeff Johnson

Post by Tim Mooney

Post by Hajducko, Steven
However, when I remove the RPM, it doesn't remove the directories because
they aren't empty. Should I setup a post uninstall to see if this is the
last instance of the package and if it is, manually remove those
directories?

Look up the %ghost attribute (?, token?, I'm not sure what it should be
classified as) and see if that does what you need.

%ghost won't solve removing nonempty directories. The %ghost directive,
with its mysterious name, claims ownership for a package of a pre-existing
path.

No, but if the %ghost is applied to the log files and the other files
that are created as part of the execution of the programs, then those
will be removed when the package is removed, and hence the directory will
be empty.

Post by Jeff Johnson
Establishing ownership of a directory in packaging, particularly for some
public path in which, say, modules
are installed, can be quite complicated.

:-) Don't I know it! I started a pretty lengthy thread about that exact
issue right after 4.4.7 or 4.4.8 came out and I first experienced needing
to claim directories (which I also think is The Right Thing, it's just
hard to do in some cases because of ambiguous ownership).

Tim

[Hajducko, Steven]

Cool, thanks for the sage words of advice guys.

As it turns out, the RPM would own this directory, because it's installing to it's own directory under /opt and it's in that directory that it's creating these files during run time.

Unfortunately, I can't possibly know the name of each file that it's going to create ( it creates ssl certs based on the hosts that connect to it.. ), so it looks like the %ghost attribute isn't going to work and I'll just have to go along with uninstall scripts.

Thanks again

--
sh

-----Original Message-----
Sent: Wednesday, May 21, 2008 10:08 PM
To: RPM Package Manager
Subject: Re: Removing directories/files in RPM erase
In regard to: Re: Removing directories/files in RPM erase,

Post by Jeff Johnson

Post by Tim Mooney

Post by Hajducko, Steven
However, when I remove the RPM, it doesn't remove the directories
because they aren't empty. Should I setup a post

uninstall to see

Post by Jeff Johnson

Post by Tim Mooney

Post by Hajducko, Steven
if this is the last instance of the package and if it is,

manually

Post by Jeff Johnson

Post by Tim Mooney

Post by Hajducko, Steven
remove those directories?

Look up the %ghost attribute (?, token?, I'm not sure what

it should

Post by Jeff Johnson

Post by Tim Mooney
be classified as) and see if that does what you need.

%ghost won't solve removing nonempty directories. The %ghost
directive, with its mysterious name, claims ownership for a

package of

Post by Jeff Johnson
a pre-existing path.

No, but if the %ghost is applied to the log files and the
other files that are created as part of the execution of the
programs, then those will be removed when the package is
removed, and hence the directory will be empty.

Post by Jeff Johnson
Establishing ownership of a directory in packaging,

particularly for

Post by Jeff Johnson
some public path in which, say, modules are installed, can be quite
complicated.

:-) Don't I know it! I started a pretty lengthy thread about
that exact issue right after 4.4.7 or 4.4.8 came out and I
first experienced needing to claim directories (which I also
think is The Right Thing, it's just hard to do in some cases
because of ambiguous ownership).
Tim
--
Tim Mooney
Information Technology Services [phone] (Voice)
Room 242-J6, IACC Building [phone] (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Lars Vagt]

Post by Hajducko, Steven
Unfortunately, I can't possibly know the name of each file that it's going to create ( it creates ssl certs based on the hosts that connect to it.. ), so it looks like the %ghost attribute isn't going to work and I'll just have to go along with uninstall scripts.

I've seen %ghost directives with wildcards. (I never used one.)

HTH, Lars

[Jeff Johnson]

Post by Tim Mooney

Post by Jeff Johnson

Post by Tim Mooney

Post by Hajducko, Steven
However, when I remove the RPM, it doesn't remove the directories because
they aren't empty. Should I setup a post uninstall to see if this is the
last instance of the package and if it is, manually remove those
directories?

Look up the %ghost attribute (?, token?, I'm not sure what it should be
classified as) and see if that does what you need.

%ghost won't solve removing nonempty directories. The %ghost
directive,
with its mysterious name, claims ownership for a package of a pre-
existing path.

No, but if the %ghost is applied to the log files and the other files
that are created as part of the execution of the programs, then those
will be removed when the package is removed, and hence the directory will
be empty.

Yes would "work" for if the file names are known.

Hmmm ... I could likely sneak a glob into RPMTAG_BASENAMES
for %ghost files, expanding and looping over unlink(2). But there
are large issues with, say ../../../../../../../* globs expanded in a
unlink(2)
loop.

Post by Tim Mooney

Post by Jeff Johnson
Establishing ownership of a directory in packaging, particularly
for some public path in which, say, modules
are installed, can be quite complicated.

:-) Don't I know it! I started a pretty lengthy thread about that exact
issue right after 4.4.7 or 4.4.8 came out and I first experienced needing
to claim directories (which I also think is The Right Thing, it's just
hard to do in some cases because of ambiguous ownership).

Yes lengthy and the issue of ownership of directories as well as
parent directory and symlink endpoint dependencies is arcane and
tedious support.

If up to me, I'd create one (or more) directory skeleton packages
like in the file system package, and move on to more interesting
problems.