On Wed, 25 Feb 2004 15:58:21 -0500, Jakub Jelinek wrote: Sure. Glad to help. I'll look it over later today. Sorry, I didn't make that clear. I didn't mean why isn't macros.prelink in the tarball, I meant why isn't it provided as a separate file and listed in the spec as - e.g. - "Source5: macros.prelink". It cleans up the spec, and doesn't break vim's highlighting. OK here goes. First I think that it's a bit OTT for people to expect every file on the FSH to be "owned". /var/log/* is a good example. IMHO packages should not own logs, only root should own that, since removing a package doesn't necessarily mean that the logs are no longer needed. OTOH if the package *is* going to own the log then I think it should ensure that it is properly managed, which includes log rotation. The main thing (for me) about logrotate, is not that it creates log archives, but more the fact that it keeps the current log size manageable. Oops, different package, sorry. I was just quoting from memory, and I was thinking about the build logs from perl-Tk, not your package. Beats me, I'm just quoting rpmlint. The two files it complained about are prelink.full and prelink.log. The other ghost file, prelink.force, is mentioned in %post (touch /var/lib/misc/prelink.force), but the other two are not. Putting them in there shuts up rpmlint. Glad someone agrees with me on that. Maybe I missed it, but I've been waiting for a "blacklist enabled" version to make it into stable (or is that updates-released), since that's where my up2date/yum/apt sources point to. Did I miss it? - K.

On Thu, 26 Feb 2004, Michael Schwendt wrote: Be careful Michael, you're now questioning official fedora.us policy. -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

On Thu, 26 Feb 2004, Panu Matilainen wrote: I know you were and I've seen more people against that policy than in favor of it on the mailinglist. Well, I'd like to see the votes again ;) As my impression was that decisions were made on IRC and/or mainly based on expressions by a famous Red Hat developer I dare not mention ;) We've got some others like the infamous 'Epoch must be included even if zero' decision, or the 'Source-tag may not have macros' decision, or the 'We dont like to mix repositories' decision and countless others. In the end I think those people that cared, didn't vote anymore. I know I didn't. -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

On Thu, 2004-02-26 at 18:44, Paul Heinlein wrote: The discussion was on fedora.us lists but it has never been a "decision" or mandatory IIRC. Anyway many people doing QA prefer macroless URLs because it makes upstream source verification easier (think copy-paste). (On the other hand, proper upstream source verification is not IMO satisfied just by copy-pasting the URL and verifying the md5sum, but to also check that it's the expected, in some way official URL. And iff SourceX's are *not URLs*, I can't figure out why macros shouldn't be used as much as possible. So it really does not matter much. History has shown though that URLs with macros tend to bitrot, resulting in incorrect URLs every now and then. Not that it would be a huge deal or a "blocker" either :)

On Thu, 26 Feb 2004 18:40:18 +0100 (CET), Dag Wieers wrote: Yes, because the build would fail in %setup. And the QA person takes a look at the src.rpm diff against the previous release. --

On Thu, 26 Feb 2004, Toshio wrote: If it is non mandatory, why are we still discussing this ? Yes, in my situation it wouldn't be triggered by 1] I may not be your average builder 2] I have many packages that _have_ to change the %setup line, 230 of the 622 spec-files which is over 30% (remember perl-packages ?) 3] I don't rely on QA people as I'd rather automate and assume a QA person has better things to do. But since it's not mandatory, let's not go into this deeper. -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

On Thu, 26 Feb 2004, Michael Schwendt wrote: I didn't say a QA person wouldn't be useful, did I ? Rather that we do things in such a way that it prevents extra QA, if it fails it fails with the packager and not a couple of hours/days later when it gets QA'd. I don't like switching context. I don't know what's wrong except that I have an older version and missing BuildRequires (which I don't think matters that much). The new version builds without any modification to the spec and I really don't see what QA has to do with it. If there's something I missed I'm sure you would tell me. So thanks for letting me know there's a newer version. I should really script something that helps me find newer versions automatically. PS You don't need the CFLAGS="-O2" (anymore?), the %makeinstall macro works too and I would %config(noreplace) the config-file. Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

On Thu, 26 Feb 2004, Michael Schwendt wrote: Ah, I didn't see that because it wasn't needed anymore. Thanks for making that clear now that's not needed. I'm sure you were waiting for that to throw it in my face at the right moment ;) It would have been nicer without the allegations, but I didn't expect it otherwise in the heat of this discussion. It doesn't segfault here on RH80, RH90 and RHFC1. That's why I thought you had it in place for earlier versions. Aparantly not. No harm done. But you wouldn't be using the correct macros. On a x86_64 it would get installed in /usr/lib instead of /usr/lib64. (This example doesn't have libraries, but it would have been good practice to do it everywhere if possible). Ok, then we agree to disagree. Minor issue. -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

On Thu, 2004-02-26 at 13:45, Dag Wieers wrote: Possibly because someone won't admit when they're wrong? :-) Could be me, but you'll have to show me how. Doesn't matter. I took a look at several of your perl spec's. They do: %setup -n %{rname}-%{version} which will get caught by #2 above. (Your complaint is that you can change version and forget to change source. But if you use the version macro in %setup, rpmbuild will still fail because the version and untar'd sourcedir name don't match.) That's fine. But your question was whether the QA person would catch the problem... There was a John Wayne movie where he went down the river on a barge with a fiesty old lady and a gatling gun. At the end of the movie John Wayne says "Damn she always has to get the last word." -Toshio -- Toshio <toshio(a)tiki-lounge.com&gt;

Since this has very little to do with Prelink, I changed the subject On Thu, 2004-02-26 at 13:09, Dag Wieers wrote: What I am wondering is what is the best method for packaging new items to be fedora compliant? Is there a step by step guide or a bunch of wiki articles? If not what is the Dag Wieers method as from what I have seen there is a neat bit of engineering done over and over again in those RPMS. -- Stephen John Smoogen smoogen(a)lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka --

On Thu, 2004-02-26 at 13:52, Michael Schwendt wrote: Here is a Spec file template with everything that should be defined in a way that is easily parsable by an automated service/QA_monkey_who_will_fling_dung_at_non_compliant_specfiles For things outside of this spec file, this is the order that we would like things to be in. Here are some good examples of SPEC files that you can use as reference when starting with something new. Here are things to avoid/not do because they make QA/maintainers lives heck and more likely that they will throw dung at you. -- Stephen John Smoogen smoogen(a)lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka --

On Thu, 2004-02-26 at 15:10, Michael Schwendt wrote: Well I doubt that HIPAA or ISO9xxx (or other govt documentation processes) are long on common sense.. I have to come up with a set of methods for doing this to make sure that developers have a clear documented process... that they can then ignore :P -- Stephen John Smoogen smoogen(a)lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka --

On Thu, 26 Feb 2004 18:25:03 -0500, Toshio wrote: Macros in URLs simply don't work. If you want macros in Source tags, cut off everything up to the file name like Source0: %name-%version.tar.gz and put an example download URL as a comment, e.g. # ftp://ftp.foo.bar/foo/foo-1.0.tar.gz Source0: %name-%version.tar.gz Certainly much better than weird constructs like Source0: http://www.foo.bar/%name/%version/%name-%{version}rc1.tar.gz (note the ugly "rc1" hack) Also note that only the expanded file name will appear in the RPM header, not the URL prefix. --

On Thu, 26 Feb 2004 20:20:41 -0500, Toshio wrote: Is an URL which contains macros still an URL? What do you do with an URL that contains macros? You can't cut'n'paste it into a browser, because it contains macros. So why include protocol, hostname and path in Source fields at all? How does the packager fetch a new release? Does he visit the web page from bookmarks? Or does he reconstruct a valid URL from the macros? Yes, provided that it is free of macros. --

On Thu, 26 Feb 2004 21:33:49 -0500, Toshio wrote: I doubt that. --

Panu Matilainen wrote : Let me add on this one. Yes, mach parses source and patch tags, expands them and searches the current directory for a matching file name, then searches for an already downloaded file in the chroot, and if none are found, tries to download the file. This is a feature Thomas (mach's author) implemented upon my suggestion. It makes things ("IMHO" required here, these threads about who is right or wrong when no one is either are getting boring) very easy, readable and quickly maintainable. Yes, I just update the version in the version tag when a new release is out, then launch a build, and finally inspect things. It can be as simple as that. My personal taste is to actually like tags like these : Source: http://dl.sf.net/projectname/%{name}-%{version}.tar.gz Of course, YTMV(*), and that's perfectly normal. Matthias * YTMV : Your Taste May Vary -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.09 0.19 0.22

Alan Cox wrote : One could add that inside the spec file after checking. But my point here was that copy/pasting a source tag to download it (i.e. with wget) was even more complicated than what mach is able to do. Now, in any case, if one wants checking to be done, it needs to be done "manually" with some reviewing, or something specific needs to be set up, for example checking the signature of the downloaded tarball from an asc file against a trusted key. Although this is important, it's beyond the point I was trying to make ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.96 0.97 0.74

On Thu, 26 Feb 2004 23:36:13 -0500, Lamar Owen wrote: This is not about voting how to do it. All that has been pointed out is that reviewers appreciate ready-to-use URLs, which they can cut'n'paste into console or browser to fetch a tarball from upstream. It has been pointed out that some packagers tend to obfuscate URLs with macros to a degree that is far from smart, e.g. Source0: http://foo.bar/%{name}/%{version}/%{name}-%{version}rc1.tar.gz and that is bad taste and bad style. Or it turns out, the URL hasn't been updated or verified in a longer time and is not true anymore. --

Michael Schwendt wrote : I get the point for the reviewers, but have to disagree about "far from smart" as well as "bad taste" and "bad style". RPM building is architectured around macros and macro expansions, and I find it to be what gives the real interest in creating spec files, then RPM packages. Take out the "rc1" from the above URL, and I find it to be very smart, plain taste (well, what do you expect, we're dealing with computers here) and typical spec file style. Oh, yes, I have some of those. Why? I just change the version tag above when i know a new version is available, and don't even need to go get the source file manually with an http or ftp client, not even a single copy/paste is required. And as an extra added goody, I get to be sure the URL is still correct (see my previous email about mach). Of course, YTMV(*), and that's perfectly normal. Matthias * YTMV : Well, see previous mail too :-) -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-1.91 Load : 0.17 0.21 0.14

Actually I thought that something like rpm -q --queryformat "%{SOURCE}\n" --specfile path/to/specfile.spec will do the job, but it seems that doesn't work. Nils Philippsen wrote:

On Tue, 02 Mar 2004 16:59:31 +0100, Nils Philippsen wrote: Nah, macros in Source fields are not evil. It's just that those, who use them, use them inconsequently. They fetch a new source tarball with up-to-date bookmarks and then don't update the URL in the Source field (so why put the URL there beforehand?). And the expanded URL does not make it into the binary rpm and src.rpm either. I will test-drive spectool when I think about it. But it won't stop the "whining" (-> subject), since if I found an out-of-date Source URL, it would need whining to get it fixed. ;) --

On Tue, 2004-03-02 at 10:59, Nils Philippsen wrote: Great litle tool. If you'd like some feedback, the options are not optional whereas the <what> is. It would make sense to either make --list-files the default mode (easy) or else change the usage to be: spectool [option] <mode> <specfile> where options are: --sources --patches --all --sourceN etc and mode is list-files or get-files (harder because of the dynamic nature of sourceN) Does this fit the bill as something that should go into fedora-rpmdevtool-$TNV? Then we can add to the (currently non-existent) non-showstopper checklist "Run the spec through fedora-spectool to make sure the Sources have current URLs listed and whine politely if they don't." (Although that might obscure the fact that people need to manually check that a Source URL is canonical, not just let spectool download the sources and assume they're fine....) -Toshio -- Toshio <toshio(a)tiki-lounge.com&gt;

On Fri, 27 Feb 2004, Michael Schwendt wrote: Macros work fine for me in Source tags, with URLs and without. See the xchat spec file for an example. pts/34 mharris@porkchop:~/rpmbuild/rpms/xchat$ grep Source xchat.spec Source: http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

On Fri, 27 Feb 2004, Michael Schwendt wrote: Why on earth would you wget on the commandline with an rpm macro embedded into the commandline? That is user-error. Do not cut and paste the URL from the spec file to the commandline. First of all, if you have the src.rpm installed, you _have_ the source code already, and do not need to download it. If you want to anyway for some reason, you have the URL where it is located and can hand edit it to be useable if desired, or can cut and paste the directory and go from there. I believe you can also query the spec file using --specfile to get the Source and Patch lines, however I'd have to confirm that. There are numerous places in a given spec file that you can't just cut and paste it into the commandline and use for some purpose. The intent of the specfile is to build the software and package it, not to facilitate cut and pasting things. $ rpm -qp --qf '%{source}\n' /mnt/redhat/beehive/comps/dist/fc2/xchat/2.0.7-3/SRPMS/xchat-2.0.7-3.src.rpm xchat-2.0.7.tar.bz2 Huh? The macro is there, for the same reason people use macro's in the C programming language, and other programming languages, as well as scripting languages. So that you can update a constant in one single location, and have that constant propagate throughout the file(s) that it is relevant to. By updating the single field "Version" in the spec file, that causes the %version macro to be created with the value that was supplied in the Version tag, and that value gets replaced throughout the spec file, thus making a single change propagate through everywhere necessary without requiring the developer to manually update a single constant in 50 locations. No I do not. I go to the xchat homepage located at http://www.xchat.org, find out what the latest version of it is, download all versions since the current rpm release, then create unified diffs between each release, and review them. Once I've chosen the new version to update to, I edit the spec file and modify the Version: field to match the release. That one change makes the version propagate through the spec file via macro expansion. The Source field(s) in the spec file exists for 2 main purposes: 1) To indicate to RPM, the source files it should include in the spec file. Some or all of these will either be expanded by the %setup macro later on, or will be referenced directly via %{SOURCEnn} tags somewhere in the spec file. All text leading up to the final "/" character is stripped from the filenames prior to accessing the files at build time. 2) To store the URL (if any given) in the Source field of the RPM header, for people querying the src.rpm from the commandline with rpm. 3) To provide a hint to the package maintainer or others, of where the file was obtained from. Anyone sensible can easily cut and paste the directory name, and ftp/http to that location to find out what the current source is. If all you want is the source code tarball that is in the src.rpm, then you have it already in the SOURCES directory. I'm not about to change the Source fields in any of my own spec files to hard code the version and remove the existing macro usage, which is correct, howver feel free to edit your own spec files and change the version number in 10 places every time a new version of the software you're maintaining comes out, and ensure every location is updated, and track down the bugs/problems caused if you forget in some location. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

On Fri, 27 Feb 2004, Michael Schwendt wrote: Ok, I've snipped the entire message just to focus on the one issue at hand. One place is enough. "Version:" However, to show I am open minded team player type of guy, I am willing to accept this change and change all of my own packages to meet this request if: - All major users of RPM, including Red Hat, SuSE, Mandrake, Conectiva, all major rpm repositories such as freshrpms.net, fedora.us, etc. agree upon making it an official standard which will go into the official rpm documentation. - Red Hat decides to adopt this internally as a standard, either defacto or official. Unless it is declared an official standard however, I do not see any net increase of benefit to me as a developer to do it the way that you suggest, and I do see some real world disadvantages to doing it the way you suggest. By using macros in the spec file on source lines, the package maintainer gets the following benefits: - It makes it easy to update the version throughout the spec file in one single location, and without having to remember there are two locations, which is the entire point of using a macro. - It removes an element of human error, in which you can update one of the locations and forget to update the other, possibly introducing a bug into the package where new code doesn't actually get used because both are sitting in the current directory. Additionally, the spec file syntax supports a URL tag, which generally should point to the project's official homepage. If there is no homepage, the closest thing to that should be pointed to, which sometimes is nothing more than an ftp or http directory link or similar. By following the URL link, which is unlikely to contain any macros, you can follow the links from there to download the software. This works both from the commandline using links/lynx, or mozilla or some other GUI browser. Another point, is that the number of people who actually look in the spec file is relatively small. The number of those who are likely to cut and paste any of the Source: line URLs onto the commandline for wget, is very likely much smaller than that. Since the source code is already present there already, very few people are going to want to actually go to the full URL directly and redownload the identical file that they already have. There may be a few such as yourself who have special purposes, however my main point here, is that the number of people will be extremely small, possibly one. In this case, the suggestion turns a very very slight inconvenience to someone such who rarely will ever be looking at the particular spec file or verifying it's contents and their origins, etc., and trades that in for a larger inconvenience directly upon the package maintainer, having to update the version number in 2 places constantly every time he updates the RPM package. IMHO, it isn't worth it for a package maintainer to inconvenience himself for such a small benefit to a very very small number of people out there. Additionally, it is no more difficult for the person who wants that URL, to cut and paste it in fragments to put it together, than it is for the maintainer to put the version number in 2 places. What's more, is that it could be rather easily scripted to parse the Source lines out of a spec file and reconstruct the full URLs. It might even be possible to do this by querying the specfile with the --specfile commandline switch, although I don't know what the appropriate syntax might be. Anyhow, in closing, count me in for updating my packages to do what you want, once it is a widely accepted and documented standard that is being widely adhered to by the rpm packaging populace. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 February 2004 16:31, Dag Wieers wrote: Personally, I would like a concrete document so I know which way to do things. Dag has been kindly helping me a lot, and regarding submitting packages, I would like to be 100% sure that the way I am learning is the right way and will be accepted for submission (depending on the quality of the specfile obviously). I have changed to Dag's way at the moment ;-) Thanks again Dag. - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com

On Thu, 26 Feb 2004 17:31:57 +0100 (CET), Dag Wieers wrote: Is it a policy? A policy as in "blocker criterion"? ;) Great. I tell you what: I don't care. Because it would mean that a src.rpm taken from Red Hat Enterprise Linux and modified slightly would be insufficient. That cannot be true, in particular not with regard to the "patches" repository. As pointed out by me quite some time ago, I find some of the groundwork over-ambitious. But I haven't seen anyone blocking the release of a working package because it used %buildroot. Most packages have lots of other issues, real issues. Which has had a good reason. Macros in URLs simply don't work. If you want macros in Source tags, cut off everything up to the file name like Source0: %name-%version.tar.gz and put an example download URL as a comment, e.g. # ftp://ftp.foo.bar/foo/foo-1.0.tar.gz Source0: %name-%version.tar.gz Certainly much better than weird constructs like Source0: http://www.foo.bar/%name/%version/%name-%{version}rc1.tar.gz (note the ugly "rc1" hack) That's more of a "we cannot -- unless there would be very tight cooperation". --

On Thu, 2004-02-26 at 18:45, Ville Skyttä wrote: "should be replaced with $RPM_BUILD_ROOT", combined with QA complaining about %{buildroot} usage makes it mandatory in practise. If it's not supposed to be mandatory then the QA checklist should say "check for consistent use of %{buildroot} vs $RPM_BUILD_ROOT" instead of what's there now. It's not like things like this are the biggest deal in existence, it's just IMHO an arbitrary rule which to me are somewhat irritanting. - Panu -

On Thu, 26 Feb 2004 18:33:28 +0100 (CET), Dag Wieers wrote: That infamous "QA checklist" is misunderstood frequently. It is hopelessly incomplete. If you go through it step by step upon reviewing a package, you can miss many other issues. If, however, the checklist were extended, it would grow *a lot* and increase the hurdle to QA significantly. The list in its current form just gives inspiration on what might be worth examining. --

On Thu, 26 Feb 2004 19:39:31 +0100 (CET), Dag Wieers wrote: What would that change? We've talked about it, criticism has been noted, and as I've tried to make clear, the checklist should not be misunderstood. There is no silver bullet. One could create a different checklist for every different type of package. The biggest hurdle to QA is lack of common sense. I don't want to spend a lot of time editing documentation in the Wiki to please a single individual (read "you") who runs his own independent repository and doesn't really care. I'd rather like to know how to lower the hurdle for other people who would like to help, but who still don't know where to start. And that would mean that they start talking about any problems they see. --

On Thu, 26 Feb 2004 21:48:55 +0100 (CET), Dag Wieers wrote: Because the list doesn't say anywhere that it would be a list of mandatory items. Do you see anything more serious in the list that ought to be changed? Or do we spend dozens of messages on just $RPM_BUILD_ROOT vs. %buildroot? The explanation, why $RPM_BUILD_ROOT is suggested, is linked in the checklist. Everybody can read where it comes from and judge by himself whether %buildroot might be killed without warning. No, I don't understand why you feel the need to discuss minor things like this and make a mountain out of a molehill. If not RPM_BUILD_ROOT, I'm sure you would find something else. I mean, even if someone modified the checklist today, you would not contribute any packages to fedora.us, because you're entirely happy with your own repository and full control over your own releases. Am I wrong? --

On Thu, 26 Feb 2004 22:34:59 +0100 (CET), Dag Wieers wrote: Yes, and the Red Hat engineer would not change that anyway unless there were good reason. The fedora.us documents don't say anywhere that $RPM_BUILD_ROOT would be "better than" or "more correct than" %buildroot. They just say that $RPM_BUILD_ROOT is preferred at fedora.us and give the reason why that is the case. With your early replies you started a not so friendly sounding policy debate, e.g. in Message-ID: <Pine.LNX.4.58.0402261717460.2334(a)horsea.3ti.be&gt; and you didn't stop at $RPM_BUILD_ROOT vs. %buildroot. --

On Thu, 26 Feb 2004 23:09:34 +0100 (CET), Dag Wieers wrote: Again, $RPM_BUILD_ROOT is preferred at fedora.us as long as it is described as the "official supported" mechanism on getting access to buildroot. Does such a thing exist? Isn't in work-in-progress still? "Me too" comments as private replies to me would be appreciated. It would be important that people, who want to contribute, or potential contributors voice their opinion. Are you kidding? That's a completely unfounded suspicion. --

On Fri, 27 Feb 2004, Lamar Owen wrote: I'm kindof rather amused by people arguing over "Which should be used $RPM_BUILD_ROOT or %{buildroot}?" so violently. It's very emacs versus vi'ish indeed. ;o) For the record, I use RPM_BUILD_ROOT exclusively myself, but only because that's what I started using way back when, and it just stuck. Considering the fact that there are a massive number of RPM packages in existance both inside the distribution and outside of it which use either one of the two, removal of either one of them would essentially break anywhere from 40-60% of all src.rpms in existance at a guess. The likelyhood of that major of a change happening to rpm *ever*, is very unrealistic IMHO, and so it really makes no difference which people use, so arguing vehemently about which one is more "correct" is a sheer and utter waste of time. ;o) That said, if there ever was an officially declared standard that was adopted by Red Hat, Mandrake, SuSE, all major 3rd party repositories, I would switch all my spec files in a heartbeat to comply, but the likelyhood of that ever actually happening is very small IMHO. Why not argue instead about why RPM's %if/%ifarch macros are not nestable? Or why there is no %elseif? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

On Fri, 27 Feb 2004, Michael Schwendt wrote: I haven't skipped any messages. I have however formed an opinion. My opinion is that a lot of people like to argue endlessly about very pointless and trive details of rpm packaging, to extreme pedantism. Most of the arguments being purely of preferential nature, with no real right or wrong way, although both sides will generally declare their way right, and the other way totally and insanely wrong. The other side then argues back with a similar but inverted argument, pointing out equally preferential arguments to prove the first person (or people) are wrong and they are right. In the end, nothing actually happens other than 2 groups of people arguing with each other, neither of whom is going to convince the other group to change their mind. Nobody changes their mind, and each group goes on doing things the way that they think is best, and then attacking each other once every n days/weeks/months whenever another person brings up the same topic. It really is very much like vi vs. emacs. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

On Fri, 27 Feb 2004, Michael Schwendt wrote: I really don't want to push it in any direction though. I'm just voicing an opinion that some of the debates people have over things are over very trivial things that don't really matter much. ;o) My own opinion may also be in that category. ;o) I myself use and prefer RPM_BUILD_ROOT over %{buildroot} due to nothing more than personal preference and years of usage. I wouldn't argue one was better than the other though. I have read jbj's mails in which he claims people should use RPM_BUILD_ROOT because he may decide to change the meaning of buildroot some day, however I don't think it's a big problem either way personally, because I know despite any such warnings, there will be a large number of packages out there anyway which would break if %{buildroot} was to get changed. A rather simple shell script can easily update such spec files some day down the road should Jeff come true on this. I'm perfectly happy with packages that use either method, despite my personal preference. Some packages even use *both*. ;o) Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 February 2004 14:19, Michael Schwendt wrote: Not only is it in progress, but it will live on our own wiki system, rather than Fedora.us'. I'm trying to limit the confusion of Fedora Legacy vs Fedora.us. Speaking of, anybody know how to DELETE a page in a wiki system? - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating

OMG ... I've started a war! Please believe that it was not my intention to do so. Feelings are obviously running high on these issues, so I guess it doesn't take much to set people off. Here's my take on the situation with regards Fedora policy. Fedora (as a distro) is still young enough to have major teething problems; let's not start fighting over issues that are still work-in-progress. As for this perception that those in charge at Fedora are overbearing Übermeisters and that policy is set in stone, I'm sure that isn't true. Let's calm down and discuss things without slinging mud at each other. Lest we forget, it was these overbearing Übermeisters who gave us a rock solid, bleeding edge, community based, distro in less than a year. My reason for getting involved with the project is simple. Like most of us, I'm an ex-Red-Hatter who migrated to Fedora. Where I discover I gap in the tools (or amusements) I need, I look for the source and package it. That's it. If I need bleeding edge enhancements in core components, I chase them up, help out where I can, and try to push through an updated release. I am filled with nothing but respect and admiration for those who work on these projects (I know from experience how time consuming and energy draining it is). I'm certainly not going to start arbitrarily cutting people up over trivial issues - if that's how I come across, then I'm sorry, and the best explanation I can offer is - when you've been burning the candle at both ends (like I very often do) then your tone comes off sounding, shall we say, a bit abrasive. It's not how I'm thinking. As for this fist fight between Micheal and Dag, let me just say that this is a real storm in a teacup. The amount of work that Dag must do to maintain his repo (single handed?) must be frightening, and his semi-automated packaging/build system is highly innovative (OK, maybe not perfect yet, but still brilliant). (Incidentally, if you're reading this Dag, I would appreciate some info on how you build your perl modules (ref: rpm macros and dependency checking), and also your kernel module packages.) I'm sure someone who works that hard without financial reward, surely cannot be described as someone who doesn't care. I package for Fedora, but I also package for Livna, but that doesn't mean that I am somehow being disloyal to the Fedora project. It isn't about picking sides, or about "them" and "us", it's about contributing towards something you believe in, and which gives you a degree of satisfaction and pleasure. I don't feel threatened by the existence of DAG-RPMS any more than I do about Livna, in fact I'm glad of having more choice. That is, after all, what "community" is all about. When I first started packaging for Fedora, despite years of experience in Unix, Linux and networking security, I simply didn't have a clue about RPM, and didn't pretend to. I was a bit taken-aback by, what I perceived as, Michael's abrasive nature. Having worked with him for the last 3 months, I can say that, although his tone is a bit dry, his attitude is very positive, and I wouldn't have reached anywhere near the level of competence I have now, without his input. Please do not mistake Michael's tone as sarcasm or arrogance, since I'm sure that he, of all people, has no interest in driving developers away from something he cares about so passionately. If Michael has a fault, it is that he is a perfectionist in the extreme, but that's his thing, and more power to him. There's little wrong with striving to protect and improve that which you believe in, and work so hard for. So please, people, let's get back to talking shop, before I start getting withdrawal symptoms from my daily fix of techno-jargon :) Oh, and yes ... I vote for keeping %{buildroot} and ditching $RPM_BUILD_ROOT. (Sorry - couldn't resist). - K. * The debuginfo package for my brain is available on my website. Please run it against gdb and forward any errors to the developer.

On Fri, 27 Feb 2004 02:24:42 +0100, Michael Schwendt wrote: Well maybe I did stretch the context a bit, but even in the given context, I find it hard to believe that Dag doesn't care about fedora.us. If he didn't care, then he wouldn't keep questioning Fedora policy? Anyway, those are questions for him to answer himself. I think Livna would shut down without Dams, and if you and Warren went to the Bahamas for two weeks - fedora.us would be a very quiet place indeed. Let's not get too paranoid about what *might* happen, but lets concentrate on expanding what we *do* have. Note the word "perceived". You see? Like right there, I don't know whether you're being serious or not. Maybe it's just me, or maybe it's a British "thing". We're an odd bunch :) Just watch a couple hours of Monty Python, and you'll know what I mean. Actually it was more in reference to your exacting nature on package QA, but then a (relative) novice packager like me is bound to say something like that. - K.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 27 February 2004 06:10, Panu Matilainen wrote: Why not make "Fedora Extras" a metarepository which is capable to redirect seamlessly across official and any third-party repo. Then if for example a package becomes unmaintained at the original place, it can taken up at a new place with a new packager without the user noticing the change. (BTW all you packagers are heroes, the amount of niggling trouble you remove from the world is huge). - -Andy - -- Find your answer without waiting for replies.... Searchable list archives at http://marc.theaimsgroup.com/?l=fedora-list&r=1&w=2

On Fri, 27 Feb 2004, Michael Schwendt wrote: You're probably reading too much into that... Sure, and I'm not advocating removing the QA process from the system or anything like that. I guess I'm mostly trying to say "keep down the flames" - fedora.us policies were discussed at length (mildly put) but that doesn't mean there isn't room for improvement, if somebody outside current fedora.us community suggests something it shouldn't be just shot down "because you don't care anyway". OTOH I'm curiously waiting what's RH's stand on the Extras thing (or are they going to say anything other than tell "fedora.us IS Extras"). Maybe not, but being over pedantic about some artificial rules can be, for somebody with 300 packages. If the packages work then why should the packager tweak their specs to match some artificial rules when it already works? Note the *if* in there - those 300 packages should be peer-reviewed just like anything else to see that they're ok. I'm just repeating what I've said before: fedora.us QA can be incredible nitpicking, whether it's the intention or not and that can be awfully irritating if the package already "just works" but maybe doesn't win the annual spec beauty contest :) I don't hold the silver bullet but open-mindness (trying to mentally clear off the old flamewars, meaning everybody involved, not you or anybody else specifically) would be a start I suppose. - Panu -