-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 14 Nov 2002, Oden Eriksson wrote:

> > make install shall not install %doc files. That's all. So, either you
> > remove those files from $RPM_BUILD_ROOT, either you teach make install
> > to not install files that you will %doc in filelist.
> 
> Why not let RedHat make rpm do everything while they're at it?
> 
> "rpm foo.tar.gz"
> 
> I'm starting to get _really_ annoyed with all rpm related issues... There has 
> to be a smarter package system where version of the package manager _does 
> not_ impact past or future packages as much as rpm does... rpm2deb?

1.  The 'make install' decision is that of the initial package 
maintainer, not of RPM -- if you don't want the documents 
installed, exit the makefile or Makefile.in with a patch file

2.  If you don't like that answer, the suggestion to remove 
the doc's during the package generation process with some 
simple shell scripting inline in the %make stanza, AFTER the 
'make install' will work fine -- this avoids the need for a 
patch at the risk of adding complexity to the .spec file, but 
is operfectly acceptible

3.  Failing that, at RPM package install time, any package can 
be installed without items identified in a %doc stanza -- 
there is a --nodocs option on install, and that will keep them 
out of an installed system.

Don't get annoyed with rpm -- that is the wrong target.  The
issue is poor packaging by people who will not follow the
Mandrake guildelines, and keep up with the power of the tool.

4.  It is not a matter of Red Hat building Mandrake at all -- 
it is a matter of being willing to read the man pages.

An effective packager must be being willing to participate in
the rpm-list sponsored by Red Hat, and the rpm-list sponsored
by Mathias (a Mandrake-using packager), [I challenge Mandrake 
to open subscription to its rpm-list -- it is NOT documented 
on the public webpages, anthough content from it is 
cross-posted into cooker list from time to time] 

And that packager meeds to keep up with the evoultion of the
RPM tool and _why_ and _how_ to use it well.  Both lists cited
are vendor neutral in tone and advice; I try to keep:
  http://www.rpm.org/ 
thus as well, with a public editorial mailing list explaining 
and inviting a vendor neutral expolition of RPM.

- -- Russ Herrold

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBPdPDY2S3OKZ7+5i5AQHtMwP/SzPDRbAt/n+7bPc2KQO4Po6Yr109rax9
3VAXGWHUyJE01foQa59EK9HR4q2YZzn8N0HSrRTtUqjPCmkDkDt79aPlS65mh+Rz
kEjMPhXOyzu4K0vTSRXwyvPbZSD9fcx3HLHMaikagFdMHaZ7xej9gMBmX9aoEpD6
K1dAMh/XvS0=
=w5Bt
-----END PGP SIGNATURE-----


Reply via email to