On Thu, Nov 14, 2002 at 10:38:05AM -0500, R P Herrold wrote: > 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
This simply replaces one problem for another. Patching makefiles is bound to create other bugs. It's silly to have to patch a makefile just to leave out an unneeded 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 That's better than modifying the makefile. But it's still stupid. I can think of many reasons why files might not get included that a package might install. Things from Mandrake not shipping the matrix screensaver to a package installing it's documentation in the wrong place. rpm has no way of knowing if you're doing something smart or something stupid. Ultimately it takes a human making the correct decision. Forcing us to rm everything is a waste of time. > 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. Huh? This is not a solution to the problem at hand. It's a nice option for users but does nothing for packagers. And it certainly does nothing for issues above and beyond documentation files. > 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. This does nothing to fix the tons of issues of people not following Mandrake guidelines. rpm will still blissfully build packages with bad menu systems. It still will build rpms that don't follow the allowed Groups. It still lets people use xpm's instead of pngs. It doesn't complain about gzip instead of bzip2. etc etc etc. And it shouldn't. There are legitimate reasons for violating some of these guidelines. There's a reason why they are guidelines and not rules. There is a reason why some things rpmlint calls errors and some things it calls warnings. What we really ought to do is have a flag on rpm that lets the packager say "if there is a warning stop." Then set the check to emit warnings. Then you upgrade a package to a new version you run the build with that flag. Fix any legitimate errors and go on. Ultimately this is what this change is about. Fixing updates that have missing files. > 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. Reading the man page is nice and all but there are quite a few of us that are experienced packagers. Who produce quality packages on a regular basis. And I'm willing to bet most of us don't subscribe to those lists. I get enough email on this list and others. I don't need to subscribe about the package manager. I can find plenty of documentation to help me build good packages out there. The Mandrake rpm howto (though slightly out of date) is really good. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
