[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)

Le Mer 10 juin 2009 10:59, Florian Festi a écrit :
> Nicolas Mailhot wrote:

>> 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 new trigger proposal has exactly the same problem as existing
triggers: processing which is specified in a separate package, and
happens magically if this package is available (on system or on build
root), without the packager of the current package having any control
on it. It will lead to exactly the same weird bugs and packager pain.

Again, if you think you've factored out some cool processing function,
please oh please give it a proper name/id and convince packagers to
explicitely invoke this name/id in their specs do not inject code
behind their backs.

Wishing it all to happen transparently with no packager action is
laudable, but in practice all past attempts to do so have ended up in
pain for packagers and as they say the road to hell is paved with good

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

After 8+ months factoring out font subpackage creation and being
forced by rpm limitations to do some form of automatic subpackage
creation I can plainly say this is a bad idea. Packagers need the
subpackage declarations to hang on deps, conflicts, ancillary files
like doc, etc. Packagers need the subpackage declaration to control
the size of theirs packages. Even if some package source includes 100
files with the same technical characteristics that does not mean you
want to create a monster 100-files subpackages (and this is not a
theorical argument, see TEX for example).

So, do factor out logic, do help packagers assemble subpackages by
calling common routines on the files they choose, but do not try to
select the files in their stead. Except for very trivial cases you're
going to have fallout, limitations and other unintended side-effects
all over the place.

Nicolas Mailhot

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