Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 599584 - [Future EAPI] Installed file-triggered postinst actions
Summary: [Future EAPI] Installed file-triggered postinst actions
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL: https://wiki.gentoo.org/wiki/Future_E...
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2016-11-12 11:42 UTC by Michał Górny
Modified: 2021-05-13 15:48 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-12 11:42:07 UTC
I don't think we have a bug for this already but it's kinda missing for a long time, and 'all other distros have it' kind of thing.

The idea is that we would use some kind of global (repo-scope?) triggered postinst/postrm actions that would be executed by the PM based on files installed by a package.

Right now we have two solutions here:

1. either ebuilds use eclasses like gnome2-utils and xdg-utils and manually call all necessary functions in postrm/postinst based on which files are installed by the package (i.e. developer needs to check that and keep the list up-to-date),

2. or ebuilds use eclasses like gnome2 and xdg which have creepy preinst magic that scans ${D} for installed files and control appropriate actions being run in post*. I'm not even sure if that's 100% legitimate wrt env saving.

Both solutions kinda suck since they require additional eclass logic, the former requires developer to manually check the list of installed files, the latter has a creepy logic to avoid that.


Now, the bare minimum seems to be:

a. specifying list of directories to scan for files matching a fnmatch pattern, e.g. equiv to find /usr/share/foo -name '*.foo';

b. spawning an additional postinst/postrm action when at least one file is found.

The questions are:

A. do we need to pass the list of matching files to the triggered functions? I think we could simply do that since PM has a list of installed files anyway.

B. How often should those triggers be run? Do we want to run them after every package, or just once at the end? Maybe that should be configurable per-trigger?

C. What about dependencies? Can we assume that relevant software (i.e. DEs or something like that) will pull in the necessary packages eventually? Can we assume that pkg_postinst/pkg_postrm of those packages will update/clean up the caches appropriately? Or maybe should we store some kind of 'failed to execute' state for triggers, and retry them later?

D. Do we need some degree of configuration per ebuild (i.e. disabling the trigger in some ebuilds)? How to achieve that?
Comment 1 Pacho Ramos gentoo-dev 2016-11-16 15:52:29 UTC
(In reply to Michał Górny from comment #0)
[...]
> B. How often should those triggers be run? Do we want to run them after
> every package, or just once at the end? Maybe that should be configurable
> per-trigger?
> 

For this case I think we will need to run it per package (as done currently from eclasses), to ensure the package is in a completely "installed" state. Otherwise we could have issues if other package going to be installed later needs something to be updated for being properly installed or run.

> C. What about dependencies? Can we assume that relevant software (i.e. DEs
> or something like that) will pull in the necessary packages eventually? Can
> we assume that pkg_postinst/pkg_postrm of those packages will update/clean
> up the caches appropriately? Or maybe should we store some kind of 'failed
> to execute' state for triggers, and retry them later?
> 

I think currently (from gnome eclasses point of view at least) we are trying to ensure the deps are installed usually from the package (in general the providers of the needed commands are so widely used that are present in most setups). Then, I would rely on proper RDEPENDs being pulled from the packages and a warning being shown by the package manager when it is unable to run a tool he pretends to run. That would help the maintainers to add the dependency if needed.

> D. Do we need some degree of configuration per ebuild (i.e. disabling the
> trigger in some ebuilds)? How to achieve that?

I am not sure about any valid case for skipping the update of the caches... but probably I am missing some case :S