[RFC] Should xbps-remove be aware of "noextract"?

[dmarto]

I always get "jumpy", when I remove packages that had files ignore by noextract. Such operation usually produces something like:

Removing `package-x.y.z' ...
ERROR: package-x.y.z: failed to remove `./a/b/c/d': No such file or directory
ERROR: package-x.y.z: failed to remove `./a/b/c': No such file or directory
Removed `package-x.y.z' successfully.

Maybe xbps-remove, can become aware of noextract and modify its behaviour?

I was going to directly propose a patch, but I am not sure what the "new" behaviour should be?

• try to remove the files, but silent the errors; that way there won't be orphaned/lost files
• or just skip operations on matching patterns; that way there won't be an error at all

On top of either options, a message can be added to notify about such skipped files if they do exist or something like that?

If there is a consensus on the topic, I am willing to make and submit a PR.

[Vaelatern]

can you give an example of a package that does this?

[dmarto]

Any package, that has files in a noextract location, that was installed after the introduction of the noextract location.

Packages installed before adding noextract locations, will not produce the ERRORs, as they had the files installed and can be removed now.

Example:

Add noextract=/usr/lib/systemd/* to /etc/xbps.d/something.conf

Install, lets say GPaste

• xbps-install -Suv GPaste

This will notify about the files, but in a less "scary" way (no ERRORS)

...
GPaste-3.42.6_1: file `./usr/lib/systemd/org.gnome.GPaste.service' won't be extracted, it matches a noextract pattern.
GPaste-3.42.6_1: file `./usr/lib/systemd/org.gnome.GPaste.Ui.service' won't be extracted, it matches a noextract pattern.
...

Now remove GPaste

• xbps-remove -Ro GPaste

Resulting in:

Removing `GPaste-3.42.6_1' ...
ERROR: GPaste-3.42.6_1: failed to remove `./usr/lib/systemd': No such file or directory
Updating MIME database...
Refreshing GSettings database from usr/share/glib-2.0/schemas... done.
Removed `GPaste-3.42.6_1' successfully.

The exact message and number depends on the noextract matches, and are there subfolders and etc..

[Duncaen]

Not sure if the extra work is worth it, we could just ignore ENOENT for removing files anyways.

[dmarto]

Not sure if the extra work is worth it, we could just ignore ENOENT for removing files anyways.

Sure, that works for me.

In reality, it probably matches what most users will expect

• no chance to leave files behind
• if they are already gone, no ERRs (as the "state" of the file is correct)
• solves the "drama" with orphan files for the case of noextract being added after installation of pkgs

If this is solution is acceptable to the others, here is a patch http://sprunge.us/1wcFnt?diff