I'm now working on some magic macros for EPEL5. Currently (on my machine, at least) you can use %license and don't need BuildRoot:. I'm curious about some other boilerplate constructs, though.
%defattr in %files: I've been told that even EPEL5 doesn't need this, but still it persists. Can someone verify that it really is not required? Why do people keep putting it in if so?
Cleaning %buildroot in %install:: Why is is so essential that the buildroot be cleaned as the first line of %install? I think I can make this happen magically but I'm not sure why it's needed at all.
%clean What actually goes wrong if %clean isn't there? If it's just some cruft that might be left over after a successful build, then is it really an issue if it's not present?
- J<
On 22/01/16 03:11, Jason L Tibbitts III wrote:
I'm now working on some magic macros for EPEL5. Currently (on my machine, at least) you can use %license and don't need BuildRoot:. I'm curious about some other boilerplate constructs, though.
%defattr in %files: I've been told that even EPEL5 doesn't need this, but still it persists. Can someone verify that it really is not required? Why do people keep putting it in if so?
The need for this went away with rpm 4.4, so EL-4 needed it and EL-5 does not. It's probably still there because people can't remember whether it was EL-5 or EL-6 that removed the need for it, and left it there to be on the safe side.
Cleaning %buildroot in %install:: Why is is so essential that the buildroot be cleaned as the first line of %install? I think I can make this happen magically but I'm not sure why it's needed at all.
%clean What actually goes wrong if %clean isn't there? If it's just some cruft that might be left over after a successful build, then is it really an issue if it's not present?
Might these affect people doing short-circuit builds? That's never been a part of my workflow so I've not come across any issues with it.
Paul.
On Fri, Jan 22, 2016 at 1:45 AM, Paul Howarth paul@city-fan.org wrote:
On 22/01/16 03:11, Jason L Tibbitts III wrote:
I'm now working on some magic macros for EPEL5. Currently (on my machine, at least) you can use %license and don't need BuildRoot:. I'm curious about some other boilerplate constructs, though.
%defattr in %files: I've been told that even EPEL5 doesn't need this, but still it persists. Can someone verify that it really is not required? Why do people keep putting it in if so?
The need for this went away with rpm 4.4, so EL-4 needed it and EL-5 does not. It's probably still there because people can't remember whether it was EL-5 or EL-6 that removed the need for it, and left it there to be on the safe side.
And it's not helped by the fact that the version of rpmlint on EL 5 and 6 warns when it's missing.
"DJ" == Dave Johansen davejohansen@gmail.com writes:
DJ> And it's not helped by the fact that the version of rpmlint on EL 5 DJ> and 6 warns when it's missing.
Interesting. Well, we can fix rpmlint. And I can grep at least the rawhide specfiles for remaining instances, generate a report, and eventually get them cleaned up.
- J<
On 01/22/2016 09:10 AM, Jason L Tibbitts III wrote:
"DJ" == Dave Johansen davejohansen@gmail.com writes:
DJ> And it's not helped by the fact that the version of rpmlint on EL 5 DJ> and 6 warns when it's missing.
Interesting. Well, we can fix rpmlint.
Possibly. rpmlint is in RHEL6/7. Not sure about 5.
----- Original Message -----
On 01/22/2016 09:10 AM, Jason L Tibbitts III wrote:
> "DJ" == Dave Johansen davejohansen@gmail.com writes:
DJ> And it's not helped by the fact that the version of rpmlint on EL 5 DJ> and 6 warns when it's missing.
Interesting. Well, we can fix rpmlint.
Possibly. rpmlint is in RHEL6/7. Not sure about 5.
Yes, rpmlint is in EL5. Actually Red Hat 7.x (Pre Fedora era).
"PH" == Paul Howarth paul@city-fan.org writes:
PH> does not. It's probably still there because people can't remember PH> whether it was EL-5 or EL-6 that removed the need for it, and left PH> it there to be on the safe side.
That's good to know. I also think there's more than a fair amount of cargo cult spec writing going on. "I'll just copy this package that works. What's this %defattr thing? No idea, but it must be important; I'll just leave it there."
This is why I'm spending so much time trying to clean these things up. Many packagers just don't understand why all of this random stuff shows up in a spec. I would like for far less random stuff to ever be in a spec.
PH> Might these affect people doing short-circuit builds? That's never PH> been a part of my workflow so I've not come across any issues with PH> it.
I do not believe so, since the final spec after macro expansion is just a normal spec. What's happening is really not that much different then what, say, the fontpackages macros do when they generate sections, or the way that debuginfo packages are generated now.
However, if someone who actually does short-circuit builds could give me some things to try, I'd be more than happy to do some testing.
- J<
On 22 Jan 2016 16:49, "Jason L Tibbitts III" tibbs@math.uh.edu wrote:
"PH" == Paul Howarth paul@city-fan.org writes:
PH> does not. It's probably still there because people can't remember PH> whether it was EL-5 or EL-6 that removed the need for it, and left PH> it there to be on the safe side.
That's good to know. I also think there's more than a fair amount of cargo cult spec writing going on. "I'll just copy this package that works. What's this %defattr thing? No idea, but it must be important; I'll just leave it there."
This is why I'm spending so much time trying to clean these things up. Many packagers just don't understand why all of this random stuff shows up in a spec. I would like for far less random stuff to ever be in a spec.
PH> Might these affect people doing short-circuit builds? That's never PH> been a part of my workflow so I've not come across any issues with PH> it.
I do not believe so, since the final spec after macro expansion is just a normal spec. What's happening is really not that much different then what, say, the fontpackages macros do when they generate sections, or the way that debuginfo packages are generated now.
However, if someone who actually does short-circuit builds could give me some things to try, I'd be more than happy to do some testing.
Wouldn't surprise me if it was an artifact that has carried on through the ages from before we had mock and build systems didn't get clean environments from that each build, so cleaning was a sensible thing.
Jason L Tibbitts III tibbs@math.uh.edu wrote:
I also think there's more than a fair amount of cargo cult spec writing going on. "I'll just copy this package that works. What's this %defattr thing? No idea, but it must be important; I'll just leave it there."
I bet. Not only is imitation a natural way of learning, but it's actually quite difficult to find complete and up-to-date documentation on how to write an RPM spec. As a beginner packager I often thought to myself that the RPM documentation seems to be mostly oral tradition. Searching the Web one may find Maximum RPM, but it's rather old and covers only the basics. There are some wiki pages that document various macros, but they're difficult to find, incomplete and sometimes outdated. The packaging guidelines contain lots of "do this" and "don't do that", but their purpose isn't to be comprehensive documentation. Various aspects of how macros are expanded and spec files are parsed can only be learned through experimentation. So imitating others' spec files is the only realistic way to learn how to make a package.
Björn Persson
"BP" == Björn Persson <Bjorn@rombobjörn.se> writes:
BP> [...] it's actually quite difficult to find complete and up-to-date BP> documentation on how to write an RPM spec.
The guide spot started which lives at https://fedoraproject.org/wiki/How_to_create_an_RPM_package is the best I've seen. I believe it's pretty much up to date. If you can recall the "newbie" experience and see questions which aren't answered there, please feel free to add things.
- J<
epel-devel@lists.fedoraproject.org
-
Björn Persson -
Dave Johansen -
Ding Yi Chen -
James Hogarth -
Jason L Tibbitts III -
Orion Poplawski -
Paul Howarth