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

[Nicolas Mailhot]

Le lundi 08 juin 2009 à 20:13 +0200, Florian Festi a écrit :
>  
> This approach has several shortcomings (forgetting the technical 
> details). It requires a lot of data be shipped with each package.

I think you misunderstood me. I'd want the definition for %font of %
icon-dir to be factored-out and centralized too (and not necessarily in
an rpm subpackage BTW, a %lib definition shipped with glibc would be
perfectly fine with me).

Also, that does not prevent standardising install locations (that's why
I ask something that can hook in %install). My example, %doc, already
makes file location decisions BTW.

What I don't want is 

1. something auto-triggered transparently (didn't we learn anything from
existing package triggers?). Some of us do not have the luxury of
uniform-quality input files. Therefore, I want the decision to launch
the processing packager-side. I want the packager to decide and check
some processing is right for his files, and not discover at QA time
another packager decided his file looked like a candidate for froobing
and should be froobed behind his back. The existing auto-processing (for
example debuginfo generation) has been wrong so many times the web is
littered with way to disable it (often with side-effects). Just because
you can write good froobing rules does not mean you understand how to
auto-select files to be froobed accurately.

2. something that auto-generates (sub)packages. The packager should
decide how big or small his packages will be, if they deserve splitting
or not, etc. Auto-package creation leads in many cases to monster
packages to big to be installed in any reasonable system.


-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090608/8e147cb8/attachment.bin