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

[Florian Festi]

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