[Rpm-ecosystem] file trigger design: opt out of file list?

Vít Ondruch vondruch at redhat.com
Fri Jul 28 14:20:17 UTC 2017



Dne 28.7.2017 v 14:57 Colin Walters napsal(a):
> Hi, so we just completed an implementation of %transfiletriggerin for rpm-ostree:
> https://github.com/projectatomic/rpm-ostree/pull/869
>
> Quick aside: why did we need to do that?  Because rpm-ostree implements "offline"
> updates (while still keeping your system running untouched), which really requires
> rewriting a lot of what librpm does.    (We also have experimental support for "livefs"
> or online updates, which is mostly experimental because we haven't worked through
> what the UI/UX is mixing offline/online updates; even live updates are transactional/atomic
> in the sense that if they're interrupted in the middle, rebooting will take you back
> to the non-live-updated state)
>
> An (IMO) cool example of the value of what rpm-ostree is doing is this:
> <https://github.com/projectatomic/rpm-ostree/pull/888>
> (We survive a %post that does rm -rf /)
> I make no claims that rpm-ostree significantly increases security if you're installing RPMs:
> <https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/>
> But our protection against *accidental* damage is quite good; I'm not aware of
> another package system doing something like this.
>
> Anyways so on to the topic at hand.  I've been looking at the specs in Fedora using
> that same tarball I was looking at in the previous thread, and it looks to me
> like the vast majority of triggers don't need the list of files piped on stdin, they
> simply walk the filesystem on their own.
>
> Again using `rpm-specs-20170518.tar.xz`:
>
> $ rep transfiletriggerin *.spec
> desktop-file-utils.spec:%transfiletriggerin -- %{_datadir}/applications
> fontconfig.spec:%transfiletriggerin -- /usr/share/fonts /usr/share/X11/fonts/Type1 /usr/share/X11/fonts/TTF /usr/local/share/fonts
> gap.spec:%transfiletriggerin -- %{gapdir}/pkg
> gdk-pixbuf2.spec:%transfiletriggerin -- %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders
> glib2.spec:%transfiletriggerin -- %{_libdir}/gio/modules
> glib2.spec:%transfiletriggerin -- %{_datadir}/glib-2.0/schemas
> gtk2.spec:%transfiletriggerin -- %{_libdir}/gtk-2.0/immodules/ %{_libdir}/gtk-2.0/%{bin_version}/immodules/
> gtk3.spec:%transfiletriggerin -- %{_libdir}/gtk-3.0/3.0.0/immodules
> man-db.spec:%transfiletriggerin -- %{_mandir}
> php-pear.spec:%transfiletriggerin -- %{pecl_xmldir}
> shared-mime-info.spec:%transfiletriggerin -- %{_datadir}/mime
> texlive.spec:%transfiletriggerin kpathsea -- %{_texdir}
> texlive.spec:%transfiletriggerin kpathsea -- %{_texdir}/texmf-dist/fonts/map/dvips/
> vagrant.spec:%transfiletriggerin -p %{_bindir}/ruby -- %{dirname:%{vagrant_plugin_spec}}
> vim.spec:%transfiletriggerin common -- %{_datadir}/%{name}/vimfiles/doc
> $ 
>
> Looking at the code, it looks like only `vagrant` and `php-pear`actually
> use rpm's file list.  And while I don't know offhand how many `php-pear` plugins
> there are, there are a grand total of 9 vagrant plugins in Fedora today - it'd
> be easy to change the vagrant spec to have the tool simply walk the filesystem
> itself.

What tool are you referring to?

Just FTR, this is the commit which introduced the %transfiletriggers:

http://pkgs.fedoraproject.org/cgit/rpms/vagrant.git/commit/?id=541f62ce638a8c73041f8507c48f55cc11c0c11a

Previously, each plugin had to call the
%vagrant_plugin_register()/%vagrant_plugin_unregister() macros. E.g.
this is how it was done:

http://pkgs.fedoraproject.org/cgit/rpms/vagrant-libvirt.git/commit/?id=a700e9f2d11d8f1e7917a2ce4c765402b10d95aa

I don't want go back to this.

Also, Vagrant would not need to traverse anything, if this was implemented:

https://bugzilla.redhat.com/show_bug.cgi?id=1301677


Vít


>
> So perhaps something like an opt-in method for triggers to say they don't
> need the file list?
>
> `%transfiletriggerin -q -- %{_datadir}/mime`?
>
> (The shared-mime info trigger is one of the bigger ones; we pass over 1000 filenames
>  to it that it ignores)
>
>
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem




More information about the Rpm-ecosystem mailing list