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