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

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée

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