Bug 469083 - tcl-tile-0.8.2 genealized tcl version determination patch
tcl-tile-0.8.2 genealized tcl version determination patch
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: koji (Show other bugs)
19
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-29 15:49 EDT by R P Herrold
Modified: 2015-02-18 06:57 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:57:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description R P Herrold 2008-10-29 15:49:36 EDT
Description of problem:

tcl-tile-0.8.2 has a hard-coded verson pathc, which is not needed


Version-Release number of selected component (if applicable):

tcl-tile-0.8.2

Patch below and Portability Fix:

Wrote: /home/herrold/rpmbuild/SRPMS/tcl-tile-0.8.2-5orc.src.rpm
Wrote: /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-0.8.2-5orc.x86_64.rpm
Wrote: /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-devel-0.8.2-5orc.x86_64.rpm
Wrote: /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-debuginfo-0.8.2-5orc.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.44379
+ umask 022
+ cd /home/herrold/rpmbuild/BUILD
+ cd tile-0.8.2
+ rm -rf /var/tmp/tcl-tile-0.8.2-5orc-o23108
+ exit 0

real    0m29.734s
user    0m9.233s
sys     0m2.856s
[herrold@centos-5 tcl-tile]$ rpm -qp --requires /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-0.8.2-5orc.x86_64.rpm | grep tcl

tcl(abi) = 8.4

[herrold@centos-5 tcl-tile]$ diff -u tcl-tile.spec-ORIG tcl-tile.spec
--- tcl-tile.spec-ORIG  2008-10-29 15:21:21.000000000 -0400
+++ tcl-tile.spec       2008-10-29 15:45:24.000000000 -0400
@@ -2,7 +2,16 @@
 # using this for the versioned Requires on tcl(abi), so we hardcode it.
 # This sucks, but there is no other clean way around it, because tcl
 # (and tclsh) aren't in the default buildroot.
-%{!?tcl_version: %define tcl_version 8.5}
+#
+#      This hardcode define breaks building on RHEL 5 when added to:
+#      Requires:       tcl(abi) = %{tcl_version}
+#      -- please consider determining tcl version, alternatively
+#      while a BuildRequires can pull tcl into the buildroot, it is not
+#      needed, as we can get it from:
+#      [herrold@centos-5 SPECS]$ rpm -qf /usr/lib64/tclConfig.sh
+#      tcl-devel-8.4.13-3.fc6
+#
+%{!?tcl_version: %define tcl_version %(echo `grep TCL_VERSION /usr/lib64/tclConfig.sh | tr -d "'" | awk -F= {'print $2'}`)}
 %{!?tcl_sitearch: %define tcl_sitearch %{_libdir}/tcl%{tcl_version}}
 %define realname tile

[herrold@centos-5 tcl-tile]$
Comment 1 Tom "spot" Callaway 2008-10-29 16:09:46 EDT
This is one of the first ideas I had when I was first developing this package, but unfortunately, it does not work in koji.

Koji tries to evaluate the tcl_version macro outside of the buildroot, where there is no tcl-devel installed, thus it errors out. See:

http://koji.fedoraproject.org/koji/getfile?taskID=911096&name=build.log

I'd be happy to do EPEL builds of this if there are interested users, the only change needed would be to alter the hardcoding to 8.4 (just like F-8).
Comment 2 R P Herrold 2008-10-29 17:45:53 EDT
What you describe is a koji shortcoming, then.

reopening and moving into that component

Koji needs to supportinstallation BR's  benore .spec file macro expansion

i.e., functionally a build needs to run in an after enumerated and implicit BR installation environment setup

This is needed to support non-manual tcl version determination derived from non-base build environment situations.
Comment 3 Jesse Keating 2008-10-29 17:52:46 EDT
Which is a bit of a problem when you may need one of those BRs just to evaluate the .spec file.  A bit of chicken/egg there.
Comment 4 R P Herrold 2008-10-29 22:08:07 EDT
?? no chickens here
I solved this years ago in cAos' autobuilder with a pre-build 
extract of just the .spec file, and grepping out ^Build lines,
and then massaging after an awk split at -F: {'print $2'}
This produces an enumeration of BR's which are passed into the
pre-installation BR completion phase, treated as Suggests (soft BR's)
Optional packages which might bring in BR's inside of conditionals 
can safely 'overpopulate' with soft BR's
What other issue remains?
Comment 5 Jesse Keating 2008-10-29 22:50:39 EDT
Well sure, if you want to bypass the rpm api all together and just manually scrape out lines, that in theory would work, although not something I'd be too keen on putting into a buildsystem.

More realistically we'll come up with an environment more suited to processing spec files.
Comment 6 R P Herrold 2008-10-29 23:37:46 EDT
The prefect vision on the hill may be an illusion. An 'agile': 
"write the test, and solve just the problem presented; refactor 
when the next use case solution permits (really 'requires')"
The problem with .spec files is that there is not a defined 'grammar'
which, taken with extensibility, makes attainment of the 'ideal' 
a _very hard_ problem.

Let me restate the matter: will you apply such a 'solve just the test
presented' patch?  If not, what is the ETA for the Platonic spec parser?
Comment 7 Jesse Keating 2008-10-30 00:03:49 EDT
Pardon me while I wade through the slurry of words...

I /think/ that our plan does what you mean, be agile and fix things as they go wrong, instead of shooting for perfect.

That is, when generating a chroot to process a spec file and build an srpm to pass around, put in the buildroot the current known set of things people expect to be able to evaluate macros within a spec.  The set is relatively small at the moment, a number of language packages plus the rpm stack.  As people add more languages or such to spec files, we can adjust the buildroot used.   This way we continue to use the rpm api to query the spec file, so that there is a canonical source for spec parsing.  We bolster this by having an "agile" config for what we put in the chroot that does the parsing.

The ETA is well "sometime in the future", but the not too distant future.  We need this to be able to support newer rpm features anyway.
Comment 8 R P Herrold 2008-10-30 00:12:03 EDT
at night, all I have is TUI pine and Lynx -- sorry about slurry

'agile' as in 'agile programming techniques'; XP made socially acceptable
Comment 9 R P Herrold 2008-10-30 14:09:32 EDT
This book is well buying and reading

The Art of Agile Development [ILLUSTRATED] (Paperback)
by James Shore (Author), Shane Warden 
# Paperback: 438 pages
# Publisher: O'Reilly Media, Inc. (October 26, 2007)
# Language: English
# ISBN-10: 0596527675

on the topic as it will make you fantastically more focused and productive
Comment 10 Bug Zapper 2008-11-25 23:27:34 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 R P Herrold 2009-07-14 10:38:17 EDT
I went to retest, and this seems to not be in today's rawHide .... Is there an issue?

Comment 5 and 7 seem not to be advancing.  May I help?

-- Russ herrold
Comment 12 Bug Zapper 2009-11-16 04:33:58 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Bug Zapper 2010-11-04 07:43:32 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 R P Herrold 2010-11-04 09:49:01 EDT
moving away from the autoclosed, as to a koji deficiency not addressed
Comment 15 Fedora Admin XMLRPC Client 2012-01-31 07:02:08 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 16 Fedora End Of Life 2013-04-03 15:51:59 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 17 Fedora End Of Life 2015-01-09 16:37:32 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 18 Fedora End Of Life 2015-02-18 06:57:47 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.