Rodrigo Barbosa wrote:
-----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.
And... what happens if the RPM generates different lists of files based
on the state of the machine it's built on?
I.e. what if it auto-detects support libraries (like openssl-devel) that
might unlock additional functionality?
What if compilation on different processors or different distros changes
the output target package? If you're using the same .spec file on 80
different machines/releases/processor families, it's hard to believe
that this isn't the case at least occasionally.
-Philip
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
