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.

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...

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.

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.

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 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.

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?

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.

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 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.

For devel that means: %fedora 7 %dist fc7 %fc7 1 will all be defined.