Re: [Cooker] new rpm and unpackaged files
From: "Ben Reser" <[EMAIL PROTECTED]> > On Fri, Nov 15, 2002 at 12:16:47AM +0200, Thomas Backlund wrote: > > How about this: > > Since there is a switch to disable the check, > > why not add a switch that changes the TERMINATE mode to WARNING mode? > > > > example: > > if this: > > %define _unpackaged_files_terminate_build 0 > > disables the check, > > why not add: > > %define _unpackaged_files_warning_build 1 > > (or whatever suitable ...) > > to change the terminate mode to warning mode. > > > > Then all should be happy, since it would give all what they want, > > > > - Terminate Mode > > - Warning Mode > > - No Warnings or Terminate mode.. > > Won't work. Then people will set that in their macros file and builds > will fail for other people. If we're going to do it anyway warning > should be default. People who want terminate should be able to enable > it. > Yep, You are right. I just thougt that since the 'disable switch' already existed, we should just add another switch, but OTOH there is nothing that stops us from removing it again ... IMHO there should only be two modes: either TERMINATE or WARNING, but NO possibility to disable it IMHO the default should be TERMINATE, since 'new' packagers probably does some/many things wrong ant this would make it harder for bugs to 'survive' ... ;-) And all 'experienced' packagers would only need to change the switch once on their own systems ... Not to much to ask from anyone, IMHO. Thomas *** Tämä viesti on VirusTarkistettu INRITEL OY:n postipalvelimella!! ***
Re: [Cooker] new rpm and unpackaged files
On Fri, Nov 15, 2002 at 12:16:47AM +0200, Thomas Backlund wrote: > How about this: > Since there is a switch to disable the check, > why not add a switch that changes the TERMINATE mode to WARNING mode? > > example: > if this: > %define _unpackaged_files_terminate_build 0 > disables the check, > why not add: > %define _unpackaged_files_warning_build 1 > (or whatever suitable ...) > to change the terminate mode to warning mode. > > Then all should be happy, since it would give all what they want, > > - Terminate Mode > - Warning Mode > - No Warnings or Terminate mode.. Won't work. Then people will set that in their macros file and builds will fail for other people. If we're going to do it anyway warning should be default. People who want terminate should be able to enable it. -- 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
Re: [Cooker] new rpm and unpackaged files
- Original Message - From: "Ben Reser" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 10:11 PM Subject: Re: [Cooker] new rpm and unpackaged files > On Thu, Nov 14, 2002 at 02:51:05PM -0500, David Walluck wrote: > > No, it's forcing the lazy developer (packager) to take an active stance. > > You sent an email complaining how no one tests packages. Well, this is a > > part of that. It forces them to not be lazy and exclude certain files > > because they just forgot to add them to the files list. > > And it creates more work for those of us who aren't lazy but might be > intentionally excluding files. > > > One drawback I see, however, is that the lazy developer will again > > become lazy and start using wildcards all over the place in the > > filelists. That's a bad idea too. > > Yup or just disabling the check by setting the macro to 0. > How about this: Since there is a switch to disable the check, why not add a switch that changes the TERMINATE mode to WARNING mode? example: if this: %define _unpackaged_files_terminate_build 0 disables the check, why not add: %define _unpackaged_files_warning_build 1 (or whatever suitable ...) to change the terminate mode to warning mode. Then all should be happy, since it would give all what they want, - Terminate Mode - Warning Mode - No Warnings or Terminate mode.. Just a thought... ;-) Thomas *** Tämä viesti on VirusTarkistettu INRITEL OY:n postipalvelimella!! ***
Re: [Cooker] new rpm and unpackaged files
Le Jeudi 14 Novembre 2002 19:23, Ben Reser a écrit : > 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. An give to packager lot of works if he have to adapt the patch at each release... -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] new rpm and unpackaged files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Reser wrote: | 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. No, it's forcing the lazy developer (packager) to take an active stance. You sent an email complaining how no one tests packages. Well, this is a part of that. It forces them to not be lazy and exclude certain files because they just forgot to add them to the files list. One drawback I see, however, is that the lazy developer will again become lazy and start using wildcards all over the place in the filelists. That's a bad idea too. | 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. Patching the Makefile is out of the question, but I also agree that removing many files is a hassle. But what is your proposed solution? | | |>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. Actually, it creates a problem for packagers since rpm will see these files as missing, whereas they were decidedly not installed, rather than missing or deleted. | 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. Yeah, but we know the solution here, and it's this: Integrate rpmlint into one of the rpm build scripts. If rpmlint fails, abort the package creation. We need to take an active stance, Mandrake employees aren't even doing it and they are getting paid. You can imagine that an unpaid voluteer is even lazier. Granted, I volunteer, but I am also passionate about anything I do. I try to take this active stance we're talking about, but some people need to be forced/have there hands held. Plus, it's easier to deny a volunteer contribs access (heck I don't even have contribs access), than it is to fire a MandrakeSoft employee who has always made sloppy packages. The community doesn't decide either directly or indirectly about people's employment. - -- Sincerely, David Walluck <[EMAIL PROTECTED]> -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE90/6oJB7s/tlHKVIRApKqAJ4qy2db/+ljqoZQN/v3IQhUtpXYLwCfeGLb K18mkQhFWkVnssruhY48XLg= =JUAK -END PGP SIGNATURE-
Re: [Cooker] new rpm and unpackaged files
On Thu, Nov 14, 2002 at 09:35:51AM -0800, David Walser wrote: > I don't think it's biggest usefulness is cleaning up > "sloppy packaging," it's useful as you upgrade a > package to a new version of software, and some files > change and you need to make changes to your %files > section, it can alert you of that. A warning would be > nicer though, there can be legitimate reasons for > leaving some files out, it's silly to have to hunt > them all down and rm them. Exactly. See my other post for a better solution for helping packagers solve this problem. -- 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
Re: [Cooker] new rpm and unpackaged files
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
Re: [Cooker] new rpm and unpackaged files
--- R P Herrold <[EMAIL PROTECTED]> wrote: > Actually it has changed in rpm-4.1 -- rpmbuild is > pointing out > 'missed' packages which the packager has built but > NOT > accounted for. It is noting sloppy packaging and > refusing to > proceed. I consider this a positive feature in > cleaning up > quality of packaging. I don't think it's biggest usefulness is cleaning up "sloppy packaging," it's useful as you upgrade a package to a new version of software, and some files change and you need to make changes to your %files section, it can alert you of that. A warning would be nicer though, there can be legitimate reasons for leaving some files out, it's silly to have to hunt them all down and rm them. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com
Re: [Cooker] new rpm and unpackaged files
On Thu, 14 Nov 2002, Gwenole Beauchesne wrote: > > How do you deal with this type of files, all are packaged under %doc, > > but > > rpm-build failed: (actually I `rm` it in spec) > > rm it from where? Under $RPM_BUILD_ROOT? Then that's normal, %doc file > is not meant to have file "installed" under $RPM_BUILD_ROOT. > > So, if you have in your build dir, saysNEWS, simply %doc NEWS, don't > install it. This behavior hasn't changed. Actually it has changed in rpm-4.1 -- rpmbuild is pointing out 'missed' packages which the packager has built but NOT accounted for. It is noting sloppy packaging and refusing to proceed. I consider this a positive feature in cleaning up quality of packaging. It is addressed in detail, along with a (not recommended) way to prevent it from refusing to certify a 'clean' build at: http://www.rpm.org/hintskinks/unpackaged-files/ (sorry about the use of a double negative in taht last sentence -- no clean declarative way to state it.) -- Russ Herrold
Re: [Cooker] new rpm and unpackaged files
-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-
Re: [Cooker] new rpm and unpackaged files
Marcel Pol ([EMAIL PROTECTED]) wrote:
>
> This last line was just user error. But I agree with Han, it should
> just warn.
I am sure they will fix the situation soon. This was just to draw our
attention. :)
> But I'm not in command at MandrakeSoft :-) But things like this make
> it really tempting to just add a filelist like this and be done with
> it.:
>
> %files
> %defattr(-,root,root)
> %{prefix}/*
And what about the files in /etc huh? :)
Besides rpmlint would complain you included dirs in the path that do not
belong to the rpm :D
//Han
--
http://www.xs4all.nl/~hanb/software
Re: [Cooker] new rpm and unpackaged files
On Thu, 14 Nov 2002 01:33:27 +0100
Han Boetes <[EMAIL PROTECTED]> wrote:
> Gwenole Beauchesne ([EMAIL PROTECTED]) wrote:
> > And who wrote this? Oh yes, Olivier. :)
> >
> > >How do you deal with this type of files, all are packaged under %doc,
> > >but rpm-build failed: (actually I `rm` it in spec)
> >
> > rm it from where? Under $RPM_BUILD_ROOT? Then that's normal, %doc file
> > is not meant to have file "installed" under $RPM_BUILD_ROOT.
> >
> > So, if you have in your build dir, saysNEWS, simply %doc NEWS, don't
> > install it. This behavior hasn't changed.
>
> 14:29 mpol| duh, rpm now complains about files which are installed but
> unpackaged 14:29 mpol| I never ran into that before. it's new?
> 14:34Han| mpol, indeed that is new.
> 14:34Han| The script it not so good. It should just warn.
> 14:34 mpol| hmm, even when I rm those files it just stops after
> /usr/lib/rpm/check-files
This last line was just user error. But I agree with Han, it should just warn.
But I'm not in command at MandrakeSoft :-)
But things like this make it really tempting to just add a filelist like this
and be done with it.:
%files
%defattr(-,root,root)
%{prefix}/*
--
Marcel Pol
Linux 2.4.19-18mdk-ringworld.1, up 3 days, 14:41
Registered User #163523
Re: [Cooker] new rpm and unpackaged files
torsdagen den 14 november 2002 08.53 skrev Gwenole Beauchesne: > Hi, > > > But this is not possible because building failed now. I want just > > confirmation about the better way to build without including this files. > > I retranslate my reply. ;-) > > 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? -- Regards // Oden Eriksson, Deserve-IT Networks Check the "Modules For Apache2" status page at: http://www.deserve-it.com/modules_for_apache2.html
Re: [Cooker] new rpm and unpackaged files
Hi, But this is not possible because building failed now. I want just confirmation about the better way to build without including this files. I retranslate my reply. ;-) 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. Bye, Gwenole.
Re: [Cooker] new rpm and unpackaged files
--- Han Boetes <[EMAIL PROTECTED]> wrote: > Gwenole Beauchesne ([EMAIL PROTECTED]) > wrote: > > And who wrote this? Oh yes, Olivier. :) > > > > >How do you deal with this type of files, all are > packaged under %doc, > > >but rpm-build failed: (actually I `rm` it in > spec) > > > > rm it from where? Under $RPM_BUILD_ROOT? Then > that's normal, %doc file > > is not meant to have file "installed" under > $RPM_BUILD_ROOT. > > > > So, if you have in your build dir, saysNEWS, > simply %doc NEWS, don't > > install it. This behavior hasn't changed. > > 14:29 mpol| duh, rpm now complains about files > which are installed but unpackaged > 14:29 mpol| I never ran into that before. it's > new? > 14:34Han| mpol, indeed that is new. > 14:34Han| The script it not so good. It > should just warn. Agreed! __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com
Re: [Cooker] new rpm and unpackaged files
On Wed, 13 Nov 2002 23:11:47 + Olivier Thauvin <[EMAIL PROTECTED]> wrote: > How do you deal with this type of files, all are packaged under %doc, > but rpm-build failed: (actually I `rm` it in spec) For those I have built that dup this behaviour I have used rm -rfd $RPM_BUILD_ROOT/xx/xx Done following %install but prior to %makeinstalll Charles Edwin Meese made me wear CORDOVANS!! -- Charles A Edwards [EMAIL PROTECTED] --
Re: [Cooker] new rpm and unpackaged files
Gwenole Beauchesne ([EMAIL PROTECTED]) wrote: > And who wrote this? Oh yes, Olivier. :) > > >How do you deal with this type of files, all are packaged under %doc, > >but rpm-build failed: (actually I `rm` it in spec) > > rm it from where? Under $RPM_BUILD_ROOT? Then that's normal, %doc file > is not meant to have file "installed" under $RPM_BUILD_ROOT. > > So, if you have in your build dir, saysNEWS, simply %doc NEWS, don't > install it. This behavior hasn't changed. 14:29 mpol| duh, rpm now complains about files which are installed but unpackaged 14:29 mpol| I never ran into that before. it's new? 14:34Han| mpol, indeed that is new. 14:34Han| The script it not so good. It should just warn. 14:34 mpol| hmm, even when I rm those files it just stops after /usr/lib/rpm/check-files 14:36 mpol| trying another package. maybe something is brken here 14:36 mpol| hum, it just works... 14:38Han| it's not broken 14:39 mpol| then something else is broken. weird 14:40 mpol| trying the previous version then 14:40Han| rm -rf /usr/lib/rpm/check-files && ln -s /usr/bin/true /usr/lib/rpm/check-files 14:40 mpol| hum, yes, that might be a nice test too. :) //Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] new rpm and unpackaged files
Le Mercredi 13 Novembre 2002 23:22, Gwenole Beauchesne a écrit : > Hi, > > > How do you deal with this type of files, all are packaged under %doc, > > but > > rpm-build failed: (actually I `rm` it in spec) > > rm it from where? Under $RPM_BUILD_ROOT? Then that's normal, %doc file > is not meant to have file "installed" under $RPM_BUILD_ROOT. > > So, if you have in your build dir, saysNEWS, simply %doc NEWS, don't > install it. This behavior hasn't changed. I retranslate my question: %make install install this files on $RPM_BUILD_ROOT/usr/share/doc, but better place is in %doc (wich have %version-%release), before latest update of rpm, all files in /usr/share/doc was not list in %files section, but we had %doc doc/*. But this is not possible because building failed now. I want just confirmation about the better way to build without including this files. Bye, thanks for this quick answer ;) -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] new rpm and unpackaged files
Hi, How do you deal with this type of files, all are packaged under %doc, but rpm-build failed: (actually I `rm` it in spec) rm it from where? Under $RPM_BUILD_ROOT? Then that's normal, %doc file is not meant to have file "installed" under $RPM_BUILD_ROOT. So, if you have in your build dir, saysNEWS, simply %doc NEWS, don't install it. This behavior hasn't changed. Bye, Gwenole.
[Cooker] new rpm and unpackaged files
How do you deal with this type of files, all are packaged under %doc, but rpm-build failed: (actually I `rm` it in spec) RPM build errors: Installed (but unpackaged) file(s) found: /usr/share/doc/prboom/AUTHORS /usr/share/doc/prboom/COPYING /usr/share/doc/prboom/MBF.txt /usr/share/doc/prboom/MBFFAQ.txt /usr/share/doc/prboom/NEWS /usr/share/doc/prboom/README /usr/share/doc/prboom/README.compat /usr/share/doc/prboom/README.demos /usr/share/doc/prboom/boom.txt [nanardon@virgo SPECS]$ rpm -q rpm rpm-4.0.4-20mdk -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
