In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
Thanks!
On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote:
In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
FWIW, I think this is a good idea.
~spot
Tom "spot" Callaway wrote:
On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote:
In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
FWIW, I think this is a good idea.
I like it too. I can think of at least one popular 3rd-party repo that gets knocked from time to time because people can't rebuild many of its packages w/o hunting down some macros...
On 29.03.2007 04:29, Jarod Wilson wrote:
Tom "spot" Callaway wrote:
On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote:
In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
FWIW, I think this is a good idea.
I like it too.
/me, too, for exactly this reason:
I can think of at least one popular 3rd-party repo that gets knocked from time to time because people can't rebuild many of its packages w/o hunting down some macros...
CU thl
On Wednesday 28 March 2007 09:23:29 pm Tom "spot" Callaway wrote:
On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote:
In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
FWIW, I think this is a good idea.
~spot
FWIW so do I
I would like to see "__arch_install_post /usr/lib/rpm/check-buildroot\n" added which we use on the extras buildsys which would require rpmdevtools be installed on every box also. which i don't think is a bad idea. it does some sanity checking on the buildroot.
On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote:
In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
I like this.
josh
On Wed, Mar 28, 2007 at 07:34:05PM -0400, Jesse Keating wrote:
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
How about making them be "fc7.local" or "fc7.$(hostname)"? I find it really convenient to be able to distinguish between locally-built and official packages.
I know I can do "rpm -q --qf '%{buildhost}\n'", so it's not that big of a deal, but it's nice to have the information more visible.
On Wed, 2007-03-28 at 22:36 -0400, Matthew Miller wrote:
On Wed, Mar 28, 2007 at 07:34:05PM -0400, Jesse Keating wrote:
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
How about making them be "fc7.local" or "fc7.$(hostname)"? I find it really convenient to be able to distinguish between locally-built and official packages.
I know I can do "rpm -q --qf '%{buildhost}\n'", so it's not that big of a deal, but it's nice to have the information more visible.
Keep in mind that you can always override these locally. :)
~spot
On Wed, Mar 28, 2007 at 09:57:41PM -0500, Tom spot Callaway wrote:
How about making them be "fc7.local" or "fc7.$(hostname)"? I find it really convenient to be able to distinguish between locally-built and official packages. I know I can do "rpm -q --qf '%{buildhost}\n'", so it's not that big of a deal, but it's nice to have the information more visible.
Keep in mind that you can always override these locally. :)
I do, and will. :)
I'm mostly thinking of it as a handy thing to have in bug reports.
On Wed, 28 Mar 2007 19:34:05 -0400, Jesse Keating wrote:
In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!).
However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step.
Thanks!
Adding macro usage without adding the macros to "something like redhat-rpm-config" is not good.
Historically, the plan has always been to add the macros to such a package. Hearing about "resistance" is news to me.
It is already unexpected and inconvenient enough to need "--define fedora 6" or similar when rebuilding some packages.
On Thursday 29 March 2007 02:53:04 Michael Schwendt wrote:
Adding macro usage without adding the macros to "something like redhat-rpm-config" is not good.
Historically, the plan has always been to add the macros to such a package. Hearing about "resistance" is news to me.
It is already unexpected and inconvenient enough to need "--define fedora 6" or similar when rebuilding some packages.
I see criticism here for how we use the buildsystem, but I don't see an actual opinion as to making these macros work on the installed system.
I assume from your last sentence that you're in favor, but I'd rather not make assumptions.
On Thu, 2007-03-29 at 06:55 -0400, Jesse Keating wrote:
On Thursday 29 March 2007 02:53:04 Michael Schwendt wrote:
Adding macro usage without adding the macros to "something like redhat-rpm-config" is not good.
Historically, the plan has always been to add the macros to such a package. Hearing about "resistance" is news to me.
It is already unexpected and inconvenient enough to need "--define fedora 6" or similar when rebuilding some packages.
I see criticism here for how we use the buildsystem, but I don't see an actual opinion as to making these macros work on the installed system.
OK you want some critical remarks:
- in a proper implementation, all "redhat" macros should be encapsulated into "target" files (/usr/lib/rpm/<target>)
- whether the build-sys macros are being merged into redhat-rpm-config doesn't matter much, because redhat-rpm-config already kills rpmbuild "--target"
- All "vendor" macros are potentially harmful (Once they are in, you almost never can get rid of them). The buildsystem macros add further to this pollution.
I assume from your last sentence that you're in favor, but I'd rather not make assumptions.
Ralf
Ralf Corsepius wrote:
- whether the build-sys macros are being merged into redhat-rpm-config
doesn't matter much, because redhat-rpm-config already kills rpmbuild "--target"
Huh? Worked just fine for me a few days ago to build i686 kernel rpms on an x86_64 host, using only the following:
$ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec
Are you referring to the fact you have to make a call to setarch to get it to fully do the right thing?
On Thu, 2007-03-29 at 09:04 -0400, Jarod Wilson wrote:
Ralf Corsepius wrote:
- whether the build-sys macros are being merged into redhat-rpm-config
doesn't matter much, because redhat-rpm-config already kills rpmbuild "--target"
Huh? Worked just fine for me a few days ago to build i686 kernel rpms on an x86_64 host, using only the following:
$ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec
Now, build for a non-rh target or an incompatible arch and examine % _host, %_build, %_target and other %values (eg. CC, or $*FLAGS)
Are you referring to the fact you have to make a call to setarch to get it to fully do the right thing?
Well, the fact you have to apply setarch is a bug.
But ... this is not related to what I am referring to: The more exotic the target are, the more brokenness you'll encounter.
E.g. try to implement custom /usr/lib/rpm/<target>/macros for an exotic target ... redhat-rpm-config causes this not to be used. rpm -e redhat-rpm-config magically makes this work ... (And this is only the tip of the iceberg :( ).
Ralf
Ralf Corsepius wrote:
On Thu, 2007-03-29 at 09:04 -0400, Jarod Wilson wrote:
Ralf Corsepius wrote:
- whether the build-sys macros are being merged into redhat-rpm-config
doesn't matter much, because redhat-rpm-config already kills rpmbuild "--target"
Huh? Worked just fine for me a few days ago to build i686 kernel rpms on an x86_64 host, using only the following:
$ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec
Now, build for a non-rh target or an incompatible arch and examine % _host, %_build, %_target and other %values (eg. CC, or $*FLAGS)
It seems a bit unreasonable to expect us to support building something like solaris sparc rpms on linux i386... Or really, building any non-rh or incompatible arch target. Even in the non-rh but still linux and a compatible arch case, a build chroot makes a lot more sense to me. Perhaps I don't fully understand what it is you're trying to accomplish.
Are you referring to the fact you have to make a call to setarch to get it to fully do the right thing?
Well, the fact you have to apply setarch is a bug.
I think that's a valid concern.
But ... this is not related to what I am referring to: The more exotic the target are, the more brokenness you'll encounter.
E.g. try to implement custom /usr/lib/rpm/<target>/macros for an exotic target ... redhat-rpm-config causes this not to be used. rpm -e redhat-rpm-config magically makes this work ... (And this is only the tip of the iceberg :( ).
Like you said, "the more exotic..." I think you're trying to do some things that the vast majority of users don't and shouldn't do. Sounds like you have a work-around already too. Not to say that if it isn't straight-forward enough we shouldn't fix up redhat-rpm-config to play nice in this situation, but I don't think its something that is going to be high-priority on most people's todo list.
Le Jeu 29 mars 2007 17:31, Jarod Wilson a écrit :
Like you said, "the more exotic..." I think you're trying to do some things that the vast majority of users don't and shouldn't do. Sounds like you have a work-around already too. Not to say that if it isn't straight-forward enough we shouldn't fix up redhat-rpm-config to play nice in this situation, but I don't think its something that is going to be high-priority on most people's todo list.
redhat-rpm-config definitively earned itself a "package from hell" reputation, to remove first when packages from other distros or older releases mysteriously do not rebuild anymore
On Thu, 2007-03-29 at 11:31 -0400, Jarod Wilson wrote:
Ralf Corsepius wrote:
On Thu, 2007-03-29 at 09:04 -0400, Jarod Wilson wrote:
Ralf Corsepius wrote:
- whether the build-sys macros are being merged into redhat-rpm-config
doesn't matter much, because redhat-rpm-config already kills rpmbuild "--target"
Huh? Worked just fine for me a few days ago to build i686 kernel rpms on an x86_64 host, using only the following:
$ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec
Now, build for a non-rh target or an incompatible arch and examine % _host, %_build, %_target and other %values (eg. CC, or $*FLAGS)
It seems a bit unreasonable to expect us to support building something like solaris sparc rpms on linux i386...
I don't expect Fedora to support such endeavors, but I do think I can expect Fedora/RH not to interfere (In a nutshell, all this can be subsumed as redhat-rpm-config breaks "rpmbuild --target").
Fact is, I am using rpm/rpmbuild to cross-build packages for other OSs but Fedora. rpmbuild (modulo bugs) supports it, but redhat-rpm-config interferes.
Or really, building any non-rh or incompatible arch target. Even in the non-rh but still linux and a compatible arch case, a build chroot makes a lot more sense to me. Perhaps I don't fully understand what it is you're trying to accomplish.
Are you referring to the fact you have to make a call to setarch to get it to fully do the right thing?
Well, the fact you have to apply setarch is a bug.
I should have said "IMO" ;)
I think that's a valid concern.
But ... this is not related to what I am referring to: The more exotic the target are, the more brokenness you'll encounter.
E.g. try to implement custom /usr/lib/rpm/<target>/macros for an exotic target ... redhat-rpm-config causes this not to be used. rpm -e redhat-rpm-config magically makes this work ... (And this is only the tip of the iceberg :( ).
Like you said, "the more exotic..." I think you're trying to do some things that the vast majority of users don't and shouldn't do.
That's the problem "99%" of users don't do ... has led to bugs interfering with the remaining "1%".
Sounds like you have a work-around already too.
Well, I am working on it. So far my work around is to ban redhat-rpm-config from the system I am using to build these rpms.
Not to say that if it isn't straight-forward enough we shouldn't fix up redhat-rpm-config to play nice in this situation, but I don't think its something that is going to be high-priority on most people's todo list.
Of cause, I don't expect "immediate" reaction. Fact is, I am complaining about this for years, but NOTHING has happened on RH's part. Instead I am seeing things getting gradually worser with each Fedora release.
Ralf
Ralf Corsepius wrote:
On Thu, 2007-03-29 at 11:31 -0400, Jarod Wilson wrote:
Ralf Corsepius wrote:
[...]
E.g. try to implement custom /usr/lib/rpm/<target>/macros for an exotic target ... redhat-rpm-config causes this not to be used. rpm -e redhat-rpm-config magically makes this work ... (And this is only the tip of the iceberg :( ).
Like you said, "the more exotic..." I think you're trying to do some things that the vast majority of users don't and shouldn't do.
That's the problem "99%" of users don't do ... has led to bugs interfering with the remaining "1%".
Sounds like you have a work-around already too.
Well, I am working on it. So far my work around is to ban redhat-rpm-config from the system I am using to build these rpms.
Not to say that if it isn't straight-forward enough we shouldn't fix up redhat-rpm-config to play nice in this situation, but I don't think its something that is going to be high-priority on most people's todo list.
Of cause, I don't expect "immediate" reaction. Fact is, I am complaining about this for years, but NOTHING has happened on RH's part. Instead I am seeing things getting gradually worser with each Fedora release.
I'm not aware of the exact nature of prior complaints, so forgive me if this has already been attempted, but given that this isn't high-priority for most people, I would think submitting patches to fix the situation in a way acceptable to all parties would have a better chance of making headway than simply complaining about it.
On Thu, 29 Mar 2007 06:55:53 -0400, Jesse Keating wrote:
On Thursday 29 March 2007 02:53:04 Michael Schwendt wrote:
Adding macro usage without adding the macros to "something like redhat-rpm-config" is not good.
Historically, the plan has always been to add the macros to such a package. Hearing about "resistance" is news to me.
It is already unexpected and inconvenient enough to need "--define fedora 6" or similar when rebuilding some packages.
I see criticism here for how we use the buildsystem, but I don't see an actual opinion as to making these macros work on the installed system.
I assume from your last sentence that you're in favor, but I'd rather not make assumptions.
Yes, I'm in favour of adding them.
I find it ridiculous that Fedora spec files make use of macros, which are not available after installing the distribution.
Jesse Keating wrote :
I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
I'm all for it too! :-)
1) They'll be harmless for spec files not making any use of them. 2) They'll make the right thing happen for the spec files that do.
Matthias
On Wednesday 28 March 2007 19:34:05 Jesse Keating wrote:
I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot.
After reading the feedback, I think we're all on the same page. I've asked the redhat-rpm-config maintainer that these macros be added into the redhat-rpm-config package so that they will be available on the installed system.
For devel that means:
%fedora 7 %dist fc7 %fc7 1
will all be defined.
The only "missing" macro at this point would be %__arch_install_post /usr/lib/rpm/check-buildroot
however this would bring in 48+megs of deps to redhat-rpm-config that I'm not comfortable with. This macro can be defined within a mock config or a buildsystem config, perhaps not something we need by default on end user's systems.