[Rpm-maint] [PATCH 5/5] Add a generic plugin for use by simple Collections
Panu Matilainen
pmatilai at laiskiainen.org
Fri Jun 18 14:00:25 UTC 2010
On Thu, 17 Jun 2010, Steve Lawrence wrote:
> This patch adds a generic plugin, exec.so, that should be sufficient for the
> majority of Collection actions. After all packages in a Collection have been
> installed/removed, this plugin executes the arguments by calling system(3),
> allowing for a very generic and powerful method to perform many actions.
>
> This also adds two sample macros as examples of the format, using the exec.so
> plugin.
> ---
> Makefile.am | 4 ++--
> collections/Makefile.am | 19 +++++++++++++++++++
> collections/collection.h | 12 ++++++++++++
> collections/exec.c | 31 +++++++++++++++++++++++++++++++
Care to change the directory to "plugins" instead of "collections"? These
are plugins afterall, and there will be more than just collection plugins
sooner or later, might as well lump them to a common spot.
> +rpmRC COLLHOOK_POST_ANY_FUNC(rpmts ts, const char * collname, const char * options)
> +{
> + int rc = RPMRC_FAIL;
> +
> + if (rpmChrootSet(rpmtsRootDir(ts)) || rpmChrootIn()) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[snip]
> + if (rpmChrootOut() || rpmChrootSet(NULL)) {
^^^^^^^^^^^^^^^^^^^^^
These look highly suspect, rpmChrootSet() is done already from
rpmtsSetup() and rpmtsFinish(), everything between those shouldn't need
anything more than just rpmChrootIn() and rpmChrootOut(). Calling
rpmChrootSet(NULL) makes it forget the cwd so further rpmChrootIn/Out
calls will fail.
> +%__collection_font %{__collectiondir}/exec.so /usr/bin/fc-cache
> +%__collection_java %{__collectiondir}/exec.so /usr/bin/rebuild-gcj-db
For demonstration purposes this is fine, but I'd rather see these go into
the relevant packages, eg whatever magic adding/removing fonts needs is
not rpm's business, it's fontconfig's business. If the command changed
from fc-cache to, say, fc-cache-update, it should be a matter of changing
the fontconfig package, not rpm.
Of course that brings in another complication: the "collection owner"
needs to be tracked somehow. Which makes me think it might make sense for
the collection tracking to be done simply with requires & provides. Eg
fontconfig package could provide "collection(fonts)" and packages wanting
to belong to the collection would simply require that collection. I guess
it'd need a new dependency flag, eg RPMSENSE_COLLECTION to be able to
distinguish them from regular deps, possibly with syntactic sugar .. or
perhaps store them in a new kind of dependency set (somewhat like
RPMTAG_COLLECTIONS, but with optional versions and flags) ... or
something. I need to ponder on this a bit, just food for thought for now.
- Panu -
More information about the Rpm-maint
mailing list