[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]