5:05 p.m.
An additional item has been added to the Packaging/Guidelines (as a
subsection to BuildRoot):
Prepping BuildRoot For %install
It is important to properly prepare the BuildRoot in the %install
section of your package before it is used. Every Fedora package MUST
have an %install section that begins with either:
%install
rm -rf %{buildroot}
or
%install
rm -rf $RPM_BUILD_ROOT
This is to ensure that the BuildRoot will be created fresh during the
%install section.
Also, the following has been added to Packaging/ReviewGuidelines:
- MUST: At the beginning of %install, each package MUST run rm -rf
%{buildroot} (or $RPM_BUILD_ROOT). See Prepping BuildRoot For %install
for details.
This change was approved by the Fedora Packaging Committee and ratified
by FESCO.
~spot
10:44 p.m.
"Tom \"spot\" Callaway" <tcallawa(a)redhat.com> writes:
It is important to properly prepare the BuildRoot in the %install
section of your package before it is used. Every Fedora package MUST
have an %install section that begins with either:
%install
rm -rf %{buildroot}
or
%install
rm -rf $RPM_BUILD_ROOT
Just outta curiosity, why is it not considered an RPM bug that every
specfile has to take care of this detail? Seems like it'd be trivial
to fix it once instead of memorializing this oversight in every package
till the end of time.
regards, tom lane
10:54 p.m.
Hi,
On 4/10/07, Tom Lane <tgl(a)redhat.com> wrote:
"Tom \"spot\" Callaway"
<tcallawa(a)redhat.com> writes:
> It is important to properly prepare the BuildRoot in the %install
> section of your package before it is used. Every Fedora package MUST
> have an %install section that begins with either:
> %install
> rm -rf %{buildroot}
> or
> %install
> rm -rf $RPM_BUILD_ROOT
Just outta curiosity, why is it not considered an RPM bug that every
specfile has to take care of this detail? Seems like it'd be trivial
to fix it once instead of memorializing this oversight in every package
till the end of time.
To less up your work on checking whats mandatory things are
missing
from a SPEC file, you can use rpmdevtools package in extras. This
package gives you fedora-newrpmspec command that will generate default
template with necessary fields/tags that should be present in SPEC
file.
Regards,
Parag.
12:18 a.m.
On 4/9/07, Tom Lane <tgl(a)redhat.com> wrote:
"Tom \"spot\" Callaway"
<tcallawa(a)redhat.com> writes:
> It is important to properly prepare the BuildRoot in the %install
> section of your package before it is used. Every Fedora package MUST
> have an %install section that begins with either:
> %install
> rm -rf %{buildroot}
> or
> %install
> rm -rf $RPM_BUILD_ROOT
Just outta curiosity, why is it not considered an RPM bug that every
specfile has to take care of this detail? Seems like it'd be trivial
to fix it once instead of memorializing this oversight in every package
till the end of time.
So file one :)
-Chris
--
Chris Weyl
Ex astris, scientia
6:10 a.m.
On Monday 09 April 2007 23:44:07 Tom Lane wrote:
Just outta curiosity, why is it not considered an RPM bug that every
specfile has to take care of this detail? Seems like it'd be trivial
to fix it once instead of memorializing this oversight in every package
till the end of time.
It's not that we don't consider it a bug, it's that we don't feel that
this
bug can be "fixed" in rpm any time soon. There are far bigger issues that
our RPM team are trying to tackle. So until such time that it is fixed in
rpm, we still have to manage it correctly within our specs. Same with
buildroot, etc...
--
Jesse Keating
Release Engineer: Fedora
6:15 a.m.
On Tue, 2007-04-10 at 07:10 -0400, Jesse Keating wrote:
On Monday 09 April 2007 23:44:07 Tom Lane wrote:
> Just outta curiosity, why is it not considered an RPM bug that every
> specfile has to take care of this detail? Seems like it'd be trivial
> to fix it once instead of memorializing this oversight in every package
> till the end of time.
It's not that we don't consider it a bug, it's that we don't feel that
this
bug can be "fixed" in rpm any time soon. There are far bigger issues that
our RPM team are trying to tackle. So until such time that it is fixed in
rpm, we still have to manage it correctly within our specs. Same with
buildroot, etc...
Oh come on. This is a 5 line change in rpm, at most...
6:18 a.m.
On Tue, Apr 10, 2007 at 07:10:00AM -0400, Jesse Keating wrote:
It's not that we don't consider it a bug, it's that we
don't feel that this
bug can be "fixed" in rpm any time soon. There are far bigger issues that
our RPM team are trying to tackle. So until such time that it is fixed in
rpm, we still have to manage it correctly within our specs. Same with
buildroot, etc...
We at SUSE use the following macro to make rpm delete the build root
automatically:
%__spec_build_pre %{___build_pre}\
%{?buildroot: %__rm -rf "$RPM_BUILD_ROOT"\
%__mkdir_p `dirname "$RPM_BUILD_ROOT"`\
%__mkdir "$RPM_BUILD_ROOT"\
}
(This actually fixes a tiny security issue, that's why there are
two mkdir calls...)
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
8:58 a.m.
On Di April 10 2007, Michael Schroeder wrote:
%__spec_build_pre %{___build_pre}\
%{?buildroot: %__rm -rf "$RPM_BUILD_ROOT"\
%__mkdir_p `dirname "$RPM_BUILD_ROOT"`\
%__mkdir "$RPM_BUILD_ROOT"\
}
(This actually fixes a tiny security issue, that's why there are
two mkdir calls...)
When you really need the first of the two mkdir invocations, the security
issue is not fixed:
https://www.redhat.com/archives/fedora-packaging/2007-March/msg00061.html
Regards,
Till
9:04 a.m.
On Wed, Apr 11, 2007 at 03:58:33PM +0200, Till Maas wrote:
On Di April 10 2007, Michael Schroeder wrote:
> %__spec_build_pre %{___build_pre}\
> %{?buildroot: %__rm -rf "$RPM_BUILD_ROOT"\
> %__mkdir_p `dirname "$RPM_BUILD_ROOT"`\
> %__mkdir "$RPM_BUILD_ROOT"\
> }
>
> (This actually fixes a tiny security issue, that's why there are
> two mkdir calls...)
When you really need the first of the two mkdir invocations, the security
issue is not fixed:
https://www.redhat.com/archives/fedora-packaging/2007-March/msg00061.html
Yes, I know, but it's in most cases a moot issue because the
buildroot is in /var/tmp.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
9:19 a.m.
On Mon, 2007-04-09 at 23:44 -0400, Tom Lane wrote:
"Tom \"spot\" Callaway"
<tcallawa(a)redhat.com> writes:
> It is important to properly prepare the BuildRoot in the %install
> section of your package before it is used. Every Fedora package MUST
> have an %install section that begins with either:
> %install
> rm -rf %{buildroot}
> or
> %install
> rm -rf $RPM_BUILD_ROOT
Just outta curiosity, why is it not considered an RPM bug that every
specfile has to take care of this detail? Seems like it'd be trivial
to fix it once instead of memorializing this oversight in every package
till the end of time.
This is absolutely an RPM bug. However, since RPM is riddled with bugs,
we can either hope they get fixed, or work around them with guidelines
until they get fixed.
Historically, filing bugs against items like this have been futile since
it would "change RPM's behavior", as broken as it may be.
I've personally had my fun with trying to submit RPM patches, and I'm
not interested in that sort of pain again. If you're motivated to get
this fixed in Fedora's RPM, please, feel free. We'll be happy to remove
any guidelines made obsolete by bugfixes.
~spot
9:40 a.m.
it`s realy strange that there need to be _GUIDELINES_ to fix bugs in the
specfiles.
Bugs that should just be fixed in RPM itself.
@Jesse Keating
you say that there are far bigger issues. why not just fix all the current
rpm bugs and release a fully patched version? than from a good working
version you can start adding in the bigger stuff.. whatever that might be.
There are far bigger issues that
our RPM team are trying to tackle.
Like?
2007/4/10, Tom spot Callaway <tcallawa(a)redhat.com>:
On Mon, 2007-04-09 at 23:44 -0400, Tom Lane wrote:
> "Tom \"spot\" Callaway" <tcallawa(a)redhat.com> writes:
> > It is important to properly prepare the BuildRoot in the %install
> > section of your package before it is used. Every Fedora package MUST
> > have an %install section that begins with either:
> > %install
> > rm -rf %{buildroot}
> > or
> > %install
> > rm -rf $RPM_BUILD_ROOT
>
> Just outta curiosity, why is it not considered an RPM bug that every
> specfile has to take care of this detail? Seems like it'd be trivial
> to fix it once instead of memorializing this oversight in every package
> till the end of time.
This is absolutely an RPM bug. However, since RPM is riddled with bugs,
we can either hope they get fixed, or work around them with guidelines
until they get fixed.
Historically, filing bugs against items like this have been futile since
it would "change RPM's behavior", as broken as it may be.
I've personally had my fun with trying to submit RPM patches, and I'm
not interested in that sort of pain again. If you're motivated to get
this fixed in Fedora's RPM, please, feel free. We'll be happy to remove
any guidelines made obsolete by bugfixes.
~spot
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
9:51 a.m.
On Tuesday 10 April 2007 10:40:37 Mark wrote:
@Jesse Keating
you say that there are far bigger issues. why not just fix all the current
rpm bugs and release a fully patched version? than from a good working
version you can start adding in the bigger stuff.. whatever that might be.
"fix all the current rpm bugs". If only it were that easy. Clearly we should
just fix all the current bugs in all our software and then we'd be done
right?
Some of those "bigger issues" are in fact the other bugs within RPM. I'm
not
talking about new functionality or stuff, I'm talking about real bugs in rpm
for our shipped products.
--
Jesse Keating
Release Engineer: Fedora
10:01 a.m.
oh.. that`s a big problem.
i was under the impression that RPM had a dozen small bugs and a few big
issues (but not bugs) so that`s why i said: "fix all the current rpm bugs
and release a patched version"
If the issues are so big.. can`t a redesign help?
anyway good luck.
Mark.
2007/4/10, Jesse Keating <jkeating(a)redhat.com>:
On Tuesday 10 April 2007 10:40:37 Mark wrote:
> @Jesse Keating
> you say that there are far bigger issues. why not just fix all the
current
> rpm bugs and release a fully patched version? than from a good working
> version you can start adding in the bigger stuff.. whatever that might
be.
"fix all the current rpm bugs". If only it were that easy. Clearly we
should
just fix all the current bugs in all our software and then we'd be done
right?
Some of those "bigger issues" are in fact the other bugs within RPM. I'm
not
talking about new functionality or stuff, I'm talking about real bugs in
rpm
for our shipped products.
--
Jesse Keating
Release Engineer: Fedora
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
1:30 a.m.
On Tue, 10 Apr 2007, Tom \spot\ Callaway wrote:
On Mon, 2007-04-09 at 23:44 -0400, Tom Lane wrote:
> "Tom \"spot\" Callaway" <tcallawa(a)redhat.com> writes:
>> It is important to properly prepare the BuildRoot in the %install
>> section of your package before it is used. Every Fedora package MUST
>> have an %install section that begins with either:
>> %install
>> rm -rf %{buildroot}
>> or
>> %install
>> rm -rf $RPM_BUILD_ROOT
>
> Just outta curiosity, why is it not considered an RPM bug that every
> specfile has to take care of this detail? Seems like it'd be trivial
> to fix it once instead of memorializing this oversight in every package
> till the end of time.
This is absolutely an RPM bug. However, since RPM is riddled with bugs,
we can either hope they get fixed, or work around them with guidelines
until they get fixed.
Historically, filing bugs against items like this have been futile since
it would "change RPM's behavior", as broken as it may be.
I've always been more than a bit puzzled by this... if the same logic was
applied everywhere we'd be stuck with egcs 1.x (or something) as the C
compiler because newer versions change the behavior and "break" a large
amount of existing software.
- Panu -
7:51 a.m.
At 9:30 AM +0300 4/11/07, Panu Matilainen wrote:
On Tue, 10 Apr 2007, Tom \spot\ Callaway wrote:
> On Mon, 2007-04-09 at 23:44 -0400, Tom Lane wrote:
>> "Tom \"spot\" Callaway" <tcallawa(a)redhat.com> writes:
>>> It is important to properly prepare the BuildRoot in the %install
>>> section of your package before it is used. Every Fedora package MUST
>>> have an %install section that begins with either:
>>> %install
>>> rm -rf %{buildroot}
>>> or
>>> %install
>>> rm -rf $RPM_BUILD_ROOT
>>
>> Just outta curiosity, why is it not considered an RPM bug that every
>> specfile has to take care of this detail? Seems like it'd be trivial
>> to fix it once instead of memorializing this oversight in every package
>> till the end of time.
>
> This is absolutely an RPM bug. However, since RPM is riddled with bugs,
> we can either hope they get fixed, or work around them with guidelines
> until they get fixed.
>
> Historically, filing bugs against items like this have been futile since
> it would "change RPM's behavior", as broken as it may be.
I've always been more than a bit puzzled by this... if the same logic was
applied everywhere we'd be stuck with egcs 1.x (or something) as the C
compiler because newer versions change the behavior and "break" a large
amount of existing software.
When the C compiler is changed, already compiled programs keep running.
When RPM is changed, already built RPMs stop working. /Thats/ what freezes
RPM's behavior.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
8:19 a.m.
Hi.
On Wed, 11 Apr 2007 08:51:08 -0400, Tony Nelson wrote:
When the C compiler is changed, already compiled programs keep
running. When RPM is changed, already built RPMs stop
working. /Thats/ what freezes RPM's behavior.
Bad comparison. RPM (as in the installer tool) is not equivalent
to the C compiler. rpmbuild (which is part of RPM) is, and changes
to rpmbuild do not affect already built packages, either.
8:20 a.m.
On Wed, 11 Apr 2007, Tony Nelson wrote:
At 9:30 AM +0300 4/11/07, Panu Matilainen wrote:
> On Tue, 10 Apr 2007, Tom \spot\ Callaway wrote:
>
>> On Mon, 2007-04-09 at 23:44 -0400, Tom Lane wrote:
>>> "Tom \"spot\" Callaway" <tcallawa(a)redhat.com>
writes:
>>>> It is important to properly prepare the BuildRoot in the %install
>>>> section of your package before it is used. Every Fedora package MUST
>>>> have an %install section that begins with either:
>>>> %install
>>>> rm -rf %{buildroot}
>>>> or
>>>> %install
>>>> rm -rf $RPM_BUILD_ROOT
>>>
>>> Just outta curiosity, why is it not considered an RPM bug that every
>>> specfile has to take care of this detail? Seems like it'd be trivial
>>> to fix it once instead of memorializing this oversight in every package
>>> till the end of time.
>>
>> This is absolutely an RPM bug. However, since RPM is riddled with bugs,
>> we can either hope they get fixed, or work around them with guidelines
>> until they get fixed.
>>
>> Historically, filing bugs against items like this have been futile since
>> it would "change RPM's behavior", as broken as it may be.
>
> I've always been more than a bit puzzled by this... if the same logic was
> applied everywhere we'd be stuck with egcs 1.x (or something) as the C
> compiler because newer versions change the behavior and "break" a large
> amount of existing software.
When the C compiler is changed, already compiled programs keep running.
When RPM is changed, already built RPMs stop working. /Thats/ what freezes
RPM's behavior.
Except this discussion (and several similar others) has been about rpm
*build-time* functionality. Oh and good luck trying to actually run
binaries built in lets say rpm-4.0.x era on current systems :)
- Panu -
6261
days inactive
6263
days old
16 comments
12 participants
participants (12)
-
Chris Weyl -
Jesse Keating -
Mark -
Matthias Clasen -
Michael Schroeder -
Panu Matilainen -
Parag Nemade -
Ralf Ertzinger -
Till Maas -
Tom Callaway -
Tom Lane -
Tony Nelson