[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)



Nicolas Mailhot wrote:
Le samedi 06 juin 2009 à 13:01 +0300, Panu Matilainen a écrit :

Yes, having each and every spec carry the %{!?foo:¤%&¤%} macro goo makes no sense at all.

That is pretty much what we did for fonts in F11. However many packagers
just ignored the change and didn't fix their packages.
...
I personally think it would be a huge mistake to have stuff happen
automatically based on filename/location heuristics. ...
 I'd much prefer if the packager
was left in control and specified the processing himself, for example by
allowing more magic %doc-like words in %files.
That shows the problem very well. Full control for the packagers is demanded but it is difficult to force the right (tm) behavior on the packagers. The question is do we really win something by leaving the handling of every file to the packager or do we demand to much when requiring the knowledge how to handle every type of file. I btw very much dislike the term "filename/location heuristics" in this context as it gets things wrong. File triggers is not about guessing what to do with the different files but to create, implement and then enforce rules how files of a given type are installed. This includes where these files need to be placed or how they are named - not exactly a new concept for a huge number of file types.

With the growing number of packages and file types that need special handling the burden for Fedora for handling these files is also growing. While changing/removing 95% of the scriptlets is a huge effort it will pay off - especially as lowers the level of entry for packaging.
In my ideal pony-land, we could have stuff like

%files somepackage

%font somefont.ttf
%icon-dir somedirectory
...

that injected the correct logic in %install/%pre/%post/%postun/%
posttrans etc

And I suppose some of those magic words would work on files already
installed, others on files in the build root (like %doc), and you'd need
them to interact (for example, consolidate three %font lines in a
package in a single actions, have the %font word be aware of the %
fontconfig word so one could correct font file processing with explicit
fontconfig rules, etc)
This approach has several shortcomings (forgetting the technical details). It requires a lot of data be shipped with each package. Data which can be already out of date (method of handling the files changed). It still requires the packager to know about all file types and whether they need special handling. And even worse it requires RPM to know about the different file types.

The nice about file triggers is that the package that actually knows about the file type ships the file trigger for handling it. glibc would ship the trigger for calling ldconfig and info the trigger for info files and so on.

Florian


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]