Going through this a few more times as I work on some bits inside the buildsystem.
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs. So that if we grab the requires from that srpm we'll have a pretty good idea of what we'll need to install to build the package.
is that correct/accurate/etc?
-sv
On Thu, May 12, 2005 at 01:00:41AM -0400, seth vidal wrote:
Going through this a few more times as I work on some bits inside the buildsystem.
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs. So that if we grab the requires from that srpm we'll have a pretty good idea of what we'll need to install to build the package.
is that correct/accurate/etc?
Yes, that should work. Nice idea...
greetings,
Florian La Roche
skvidal@phy.duke.edu (seth vidal) writes:
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs.
To be correct, the used algorithm should be:
deps = '' do { old-deps = deps rpm -Uvh --nodeps ....src.rpm rpmbuild -bs --nodeps --force ....spec <other-opts>* calculate-deps install deps } while deps != old-deps
Else, wrong results will be produced for cases like
| BuildRequires: foo | %macrofoo
whereas the macro is defined in /etc/rpm/macros.foo (shipped by package 'foo') and expands to
| BuildRequires: bar
Enrico
On Thu, 2005-05-12 at 01:00 -0400, seth vidal wrote:
Going through this a few more times as I work on some bits inside the buildsystem.
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs. So that if we grab the requires from that srpm we'll have a pretty good idea of what we'll need to install to build the package.
is that correct/accurate/etc?
It will fail for specs that express buildrequires using a macro that gets its result from a program that ought to be installed.
Think "python --version" and then buildrequiring the correct version by package name.
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Don't change your name keep it the same for fear I may lose you again I know you won't it's just that I am unorganized and I want to find you when Something good happens <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
On Thu, 2005-05-19 at 18:10 +0200, Thomas Vander Stichele wrote:
On Thu, 2005-05-12 at 01:00 -0400, seth vidal wrote:
Going through this a few more times as I work on some bits inside the buildsystem.
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs. So that if we grab the requires from that srpm we'll have a pretty good idea of what we'll need to install to build the package.
is that correct/accurate/etc?
It will fail for specs that express buildrequires using a macro that gets its result from a program that ought to be installed.
Think "python --version" and then buildrequiring the correct version by package name.
Right and I think we agreed that doing that could be banned from packages.
-sv
skvidal@phy.duke.edu (seth vidal) writes:
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs.
.... It will fail for specs that express buildrequires using a macro that gets its result from a program that ought to be installed.
Think "python --version" and then buildrequiring the correct version by package name.
Right and I think we agreed that doing that could be banned from packages.
... or be solved by the buildsystem...
Enrico
Think "python --version" and then buildrequiring the correct version by package name.
Right and I think we agreed that doing that could be banned from packages.
If we take Enrico's suggestion of doing the srpm/builddep items in a loop until the buildeps are the same then we would get them all.
-sv
seth vidal wrote:
Think "python --version" and then buildrequiring the correct version by package name.
Right and I think we agreed that doing that could be banned from packages.
There is no agreement here.
Core uses hacks in several packages that do just this. It has never been a problem, and it makes it easier to maintain those spec files in the long term because you avoid changes and the behavior is well understood.
https://www.redhat.com/archives/fedora-buildsys-list/2005-May/msg00021.html It is no problem if you use this algorithm.
Warren Togami wtogami@redhat.com
On Sun, 2005-05-22 at 18:42 -1000, Warren Togami wrote:
seth vidal wrote:
Think "python --version" and then buildrequiring the correct version by package name.
Right and I think we agreed that doing that could be banned from packages.
There is no agreement here.
Core uses hacks in several packages that do just this. It has never been a problem, and it makes it easier to maintain those spec files in the long term because you avoid changes and the behavior is well understood.
You don't happen to have a list of which packages those are, do you?
On Thu, 2005-05-19 at 18:10 +0200, Thomas Vander Stichele wrote:
On Thu, 2005-05-12 at 01:00 -0400, seth vidal wrote:
Going through this a few more times as I work on some bits inside the buildsystem.
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs. So that if we grab the requires from that srpm we'll have a pretty good idea of what we'll need to install to build the package.
is that correct/accurate/etc?
It will fail for specs that express buildrequires using a macro that gets its result from a program that ought to be installed.
Think "python --version" and then buildrequiring the correct version by package name.
What's a case where this would be used? Ie, you want to tie the package you're building to a _specific_ version of python? Wouldn't that be better done by actually just hardcoding the python version? If this is the usecase, that sounds lazy to me. But if not, what are some valid ones?
Dan
Hi,
What's a case where this would be used? Ie, you want to tie the package you're building to a _specific_ version of python?
No, you want your spec to build on dists *without* knowing what the version is, ie without tieing it to a specific version. IIRC that's what pyvault does in a lot of spec files.
It's also done in other spec files that were thrown at mach for f.us and livna.org - xmms plugins are an example IIRC, but I can't be sure atm.
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I know someday you'll have a beautiful life I know you'll be a star in someone else's sky but why oh why oh why why can't it be mine ? <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
On Sat, 2005-05-21 at 16:24 +0200, Thomas Vander Stichele wrote:
Hi,
What's a case where this would be used? Ie, you want to tie the package you're building to a _specific_ version of python?
No, you want your spec to build on dists *without* knowing what the version is, ie without tieing it to a specific version.
What does this solve? The build requirement (as written to the src rpm) then becomes "if by some coincidence this srpm built with this other package installed, dissalow rebuilds except against the current version of that package".
And even that doesn't really guarantee anything, because it was probably built with "-bs", so it didn't even see if the build *worked* to get that far.
Every time this gets brought up, people use this example to justify it. I agree that there are packages that _have_ this stuff in them (obviously), but I still haven't seen a good explanation of how the example isn't completely contrived.
On Thu, 2005-05-12 at 01:00 -0400, seth vidal wrote:
Going through this a few more times as I work on some bits inside the buildsystem.
We're given an srpm - we don't know where it was made, on what arch, nothing - so we cannot trust the buildreqs it provides.
If we're inside the chroot and on the arch we want to build on then running: rpm -Uvh /path/to/our/srpm rpmbuild -bs --nodeps /path/to/the/generated/spec
should result in a srpm for us that will have valid build reqs. So that if we grab the requires from that srpm we'll have a pretty good idea of what we'll need to install to build the package.
is that correct/accurate/etc?
You can actually glean that info from the spec without having to build a SRPM:
rpmbuild foo.spec 2>&1 | awk 'BEGIN { FS = "[ \t]" } $1 !~ /^error:$/ {print $2}'
buildsys@lists.fedoraproject.org
-
Dan Williams -
Enrico Scholz -
Florian La Roche -
Ignacio Vazquez-Abrams -
Peter Jones -
seth vidal -
Thomas Vander Stichele -
Warren Togami