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

Florian Festi ffesti at redhat.com
Wed Jun 10 08:59:14 UTC 2009


Nicolas Mailhot wrote:
> 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).

Yeah, but patching the spec file parsing from out side sounds scary
(Ok, may be these implementation details should be ignored at this level of 
disscussion).

> 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.
Sure.

> What I don't want is 
> 
> 1. something auto-triggered transparently (didn't we learn anything from
> existing package triggers?).

I think you make the wrong comparison here (although I admit that the 
matching names make it tempting). Triggers fill holes in the scriptlet 
mechanism and though are restricted to obscure and complicated cases.
The file trigger I am talking about will handle the easy, omnipresent cases 
where files need additional treatment. They better compare to the automatic 
dependency creation. As the automatic dependency creation file triggers 
would benefit of a good/better control by the packager.

> 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.

This probably deserves an thread on its own...

I don't think there will be any additional full automatic creation of sub 
packages in Fedora (hmm, but automatic -bin packages to get everything else 
noarch...). But semi automatic sub package creation is going to be an 
important part when/if we split out language sub packages. My idea is that 
you specify a regex for the files that go into the sub packages and a 
matching group that names the sub package and becomes a macro used in the 
package template. But before splitting out language sub packages makes sense 
we have to fix a lot of other places first. So much to do some so little time.

Florian




More information about the devel mailing list