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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
