On Wednesday, 19 September 2007, at 16:17:45 (-0600), Dmitry S. Makovey wrote: > Out of pure curiosity (and for the sake of flaming at all) could you > please give some usecases when such technique (described by Philip > P.) backfires? Building packages myself I am very interested in a > ways to improve packaging. It's not really a question of use case. It's a risk/benefit tradeoff. Packages that hardcode specific file lists are not as portable (e.g., across distros) and require greater maintenance for updates (as installed files are added or removed). However, doing it that way does mean that you'll "know" (by virtue of build failures) if any capabilities appear or disappear. I would submit that that's the wrong way to "know" such things, but I'm sure others would disagree. > For example: some packages I built contain enormous number of files > (3K+) - what do you do then? Obviously you can't enumerate all of > them and it's hard to track every single change even between > upstream revisions (changed 10 filenames etc.) You most certainly can enumerate them all. There's a difference between "can't" and "would be a pain in the ass to." :-) But again, it's a tradeoff: if you need the fine-grain dictatorial control (which I refered to as fascist) over what each package provides, you must tolerate the pain of complete manual file list enumeration. But if you believe, as I do, that packaging is descriptive, not prescriptive, using globs is not only reasonable but encouraged. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@xxxxxxxxx> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "What does not destroy me, makes me stronger." -- Nietzsche, The Twilight of the Idols (1888) _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
