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 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
