Re: New directive for %files section (%exclude)

[Rodrigo Barbosa <rodrigob darkover org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Sep 19, 2007 at 04:17:45PM -0600, Dmitry S. Makovey wrote:
> On September 18, 2007, Rodrigo Barbosa wrote:
> > On Thu, Sep 13, 2007 at 08:34:14PM -0700, Philip Prindeville wrote:
> > >  %{_libexecdir}/mod_*.so
> >
> > This is such a bad practice I almost cried from reading this e-mail.
> >
> > NEVER do this. Ever.
> >
> > If you reuse your specfile for a new version of the package, you
> > will completely loose (developer) control of which files are in
> > your package.
> >
> > Also name all your files.
> 
> 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.
> 
> 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.)
> 
> If you feel more comfortable replying off-list please do so - either way I'm 
> interested in your opinion. thanks.

This is what I would do.

I would generate a file (lets say package.lst) with a listing of
files to include. Would do this manually, and then look at that
listing and see if everything is as it should be. For the sake of
documentation, I would put a comment inside the specfile with the
command used to generate that file.

That file would then be used with %files -f package.lst.

Then, when I upgrade the software, I would generate a second file listing,
and compare the 2 (diff -u, etc). If everything was fine, I would use the
new one.

Another option would be to include that listing directly on the
specfile, or just the files that need something different than
%defattr. 

The idea is that you have control of what is there, and so you avoid
surprises.

Ok, everything will be fine, if you just use a glob, 99% of the time.
So if you are managing just 1 or 2 packages, and know them well,
that should not be a problem. However, if you are managing several
packages, this way can save you a lot of headaches trying to find out
why that package you built is not working as its last version was.

- -- 
Rodrigo Barbosa
"Quid quid Latine dictum sit, altum viditur"
"Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFG8fYdpdyWzQ5b5ckRAlQpAKCrATdDNhykgtm4F98fNHa96UqfFwCgi+Fq
UB732SH2cm2eIv8VFawQB78=
=FWQI
-----END PGP SIGNATURE-----