On Fri, 09 Jun 2006 13:36:11 -0700, Chris Petersen wrote: > > There is nothing wrong with starting from the upstream spec. It will > > have to adhere to the standards though, no flexibility on that. It > > would be best if upstream could accept the changes you have to make so > > that life is easier. > > well, since one of the standards is "no other-distro stuff in the spec," > that makes courier's incompatible. My main concern is that it's > designed to build an rpm -- on any rpm-based distro. I can clean up the > stuff that would annoy rpmlint, possibly the group name (nonstandard), > but I'm not about to maintain it in such a way that I always have to > pull out Sam's non-fedora customizations. > > For reference, the file is available at: > > http://courier.cvs.sourceforge.net/courier/courier/courier/courier.spec.in?view=markup > This one is a funny incarnation of the infamous superfluous buildroot check in the spec: > test "$RPM_BUILD_ROOT" != "" && rm -rf $RPM_BUILD_ROOT It's even less useful than checking whether buildroot is set to '/'. :-) Note that the buildroot == '/' check still seen in spec files occasionally is from times when the "BuildRoot:" tag in spec files was not mandatory and when scripts in rpmbuild did not check it either. I think it is a myth that package builders commonly lost their root directory because of this. Personally, I don't know anybody who has been hit by "rm -rf /" going wild during rpmbuild. But I've seen the occasional report of typos causing many others scripts to do this, where "safety checks" failed to recognise root == // or root == '/ ' and in one very old case even $RPM_BUILD_ROOT/ Back to the courier spec, I find it overly big and complex. Screen-filling Perl helper functions, which generate %attr(...) values on-the-fly, redefinition of several globals, e.g. > %define _missing_doc_files_terminate_build 1 > %define _unpackaged_files_terminate_build 1 > %define __libtoolize /bin/true even a "%define configure ...", > AutoProv: no spec sections with a comment like > # Break up a single filelist into multiple packages right here. This is > # going to be ugly. > ## Ok, upgrades are going to get ugly. lots of "sed" usage, build-time generated profile.{sh,csh} scripts, inline Perl script usage, chown in %post (!), > chown --reference=%{_sysconfdir} %{_sysconfdir}/userdb triggerpostun scriptlets which mess with .rpmnew files. This package looks pretty much like a maintenance nightmare. I wonder why the install process is not simplified with more work in "make install"? -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
