Bug 168190
Summary: | Review Request: gpsim - A simulator for Microchip (TM) PIC (TM) microcontrollers | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alain Portal <alain.portal> | ||||
Component: | Package Review | Assignee: | Jose Pedro Oliveira <jose.p.oliveira.oss> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | rrankin | ||||
Target Milestone: | --- | Flags: | gwync:
fedora-cvs+
|
||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
URL: | http://www.dattalo.com/gnupic/gpsim.html | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-10-10 15:10:28 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 168189 | ||||||
Bug Blocks: | 163779 | ||||||
Attachments: |
|
Description
Alain Portal
2005-09-13 11:59:30 UTC
Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-3.src.rpm * Thu Sep 15 2005 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.21.4-3 - Exclude .la file - Add examples %changelog * Mon Sep 19 2005 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.21.4-4 - Add missing a rm -rf RPM_BUILD_ROOT statement in the install section Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-4.src.rpm Created attachment 119432 [details]
specfile patch - removes the rpmlint messages
Alain,
The attached patch removes the rpmlint errors (two new commands in the %prep
section) and reformats a couple of lines. Everything else looks good and the
package builds in mock.
%changelog * Fri Sep 30 2005 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.21.4-5 - Improve prep section to make rpmlint happy - Contributions of Jose Pedro Oliveira <jpo[AT]di[DOT]uminho[DOT]pt> Thanks to him. Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/gpsim.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/gpsim-0.21.4-5.src.rpm APPROVED MD5SUMS: 1323d4df3780ba85deefcf1a8eda836d gpsim-0.21.4-5.src.rpm 42dafc3ce0b1dba8f9d2daa2a3708baf gpsim-0.21.4.tar.gz b1f6335c24e1d1bb2cd0d2131510b106 gpsim.spec Good: * Package name follows standard * Source taball MD5 digest verified * URL and Source url are valid * License verified * License text included * File permissions are ok * post/postun scripts present and valid * Builds without problems in FC3 * Builds without problems in mock (FC4) * Installs/uninstalls without problems in FC3 > Requires: gtk+extra = 1.1.0
What is the reason for requiring this strict version?
That is because the development of gtk+extra freeze during more than 3 years (http://gtkextra.sourceforge.net/ last release 0.99.17 on 12/04/2001) and the gpsim maintener need some improvements in gtk+extra. So he provide a release he need (gtk+extra 1.1.0). But gtk+extra development restart on 05/17/2005, last release is 2.1.1 on 06/24/2005 which is incompatible with current version of gpsim. (In reply to comment #7) > That is because the development of gtk+extra freeze during more than 3 years > (http://gtkextra.sourceforge.net/ last release 0.99.17 on 12/04/2001) and the > gpsim maintener need some improvements in gtk+extra. So he provide a release > he need (gtk+extra 1.1.0). > But gtk+extra development restart on 05/17/2005, last release is 2.1.1 on > 06/24/2005 which is incompatible with current version of gpsim. What you say above is multiple troublesome: 1. The gtk+extra 1.1.0 gpsim requires, is not an official version of gtk+extras. => We should _not_ ship gtk+extra-1.1.0 under the name "gtk+extra", as shipping something unofficial/derived under the original name, IMO is truely bad idea. I think we should consider to withdraw the current gtk+extra-1.1.0. 2. gtk+extra > 2.x is incompatible to gtk+extra < 1.0 => All 3 versions must be installable in parallel, should there be a corresponding demand for all 3 versions. What to do in detail, depends on packaging details of all 3 versions. 3. Requires: gtk+extra = 1.1.0 doesn't make any sense, because, to be able to ship all 3 versions, the package names must be chosen in such a way they do not conflict, e.g. gtk+extra (1.0.x) gtk+extra11 (1.1.x) gtk+extra2 (>= 2.0) > So he provide a release he need (gtk+extra 1.1.0).
There has been an official 1.0.0 release. How does the 1.1.0 unofficial
release compare with the official 1.0.0? What exactly is this 1.1.0
version? Where does it come from? Who is the one who came up with
that version number? Is it a CVS snapshot? Did the gpsim maintainer
create this version number out of thin air?
WRT Ralf's points: Full ACK.
We cannot offer an unofficial release with an unofficial version number
unless it is assured that the official release, regardless of how old it
may be, can be shipped conflict-free and using its original version and
official package name.
In addition to the explicit versioned Requires being both too strict
and too fragile, does the package provide any SONAMES which would
conflict with the official gtk+extra versions?
(In reply to comment #9) > > So he provide a release he need (gtk+extra 1.1.0). > > There has been an official 1.0.0 release. How does the 1.1.0 unofficial > release compare with the official 1.0.0? What exactly is this 1.1.0 > version? Where does it come from? Who is the one who came up with > that version number? Is it a CVS snapshot? Did the gpsim maintainer > create this version number out of thin air? As the gtk+extra development was stopped (last released was 0.99.17 on 12/04/2001 gtk1 based), Scott Dattalo, gpsim maintener, decided to port gtk+extra to gtk2 and released this port as 1.0.0 (unofficial), then 1.1.0, released on 04/29/2005. Official gtk+extra development restart and port to gtk2, and the new release was 1.0.0 on 05/17/2005. Last release is 2.1.1, on 06/24/2005. > WRT Ralf's points: Full ACK. > > We cannot offer an unofficial release with an unofficial version number > unless it is assured that the official release, regardless of how old it > may be, can be shipped conflict-free and using its original version and > official package name. > > In addition to the explicit versioned Requires being both too strict > and too fragile, does the package provide any SONAMES which would > conflict with the official gtk+extra versions? No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on official gtk+extra, sonames are libgtkextra-x11-2.0.so* What should I have to do? Create a package as gtk+extra11 for unofficial version and gtk+extra for official? (In reply to comment #10) > (In reply to comment #9) > No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on official > gtk+extra, sonames are libgtkextra-x11-2.0.so* > > What should I have to do? > > Create a package as gtk+extra11 for unofficial version and gtk+extra for > official? That won't help, because other packages potentially to be submitted could require the official gtk+extra-1.x. So you are facing several problems at once: 1. You must replace the current gtk+extra with an official package, either 2.0 or 1.0. 2. The unofficial version must not conflict with any official package. I.e. you have to provide a solution that allows a clean, parallel installation of all 3 packages, 'official old', 'official new' and 'inofficial', both devel and run-time variant packages. If following the gtk+/gtk2 naming conventions, you could to 1) Put the latest official gtk+extra-1 sources into "gtk+extra" packages and increment the epoch. 2) Ship gtk+extra >2.0 as "gtk2+extra" or "gtk+extra2" 3) Put the unofficial stuff into an arbitarily named package (say gpsim-libs) and hack the package in such a way that this version doesn't conflict with any of the official versions (Neither includes nor SONAMEs). Instead of 3) you could merge the "unofficial gtk+extras" with the gpsim package and link statically against it. Many other possibilities are possible. As usual things depend on details. The cleanest solution would be to push upstream gpsim to using the current gtk+extra2. If they can provide such a solution in not too distant future, upgrading gtk+extra to 2 and waiting with gpsim probably would be best. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on official > > gtk+extra, sonames are libgtkextra-x11-2.0.so* > > > > What should I have to do? > > > > Create a package as gtk+extra11 for unofficial version and gtk+extra for > > official? > That won't help, because other packages potentially to be submitted could > require the official gtk+extra-1.x. > > So you are facing several problems at once: > 1. You must replace the current gtk+extra with an official package, either 2.0 > or 1.0. > 2. The unofficial version must not conflict with any official package. > > I.e. you have to provide a solution that allows a clean, parallel installation > of all 3 packages, 'official old', 'official new' and 'inofficial', both devel > and run-time variant packages. > > If following the gtk+/gtk2 naming conventions, you could to > 1) Put the latest official gtk+extra-1 sources into "gtk+extra" packages and > increment the epoch. > 2) Ship gtk+extra >2.0 as "gtk2+extra" or "gtk+extra2" I have to ask the gtk+extra maintener what are the real differences between his 1.0.0 and 2.0.0 version. I am not sure that is gtk1 and gtk2, so perhaps packaging 1.0.0 won't be needed. > 3) Put the unofficial stuff into an arbitarily named package (say gpsim-libs) > and hack the package in such a way that this version doesn't conflict with any > of the official versions (Neither includes nor SONAMEs). > > Instead of 3) you could merge the "unofficial gtk+extras" with the gpsim package > and link statically against it. > > Many other possibilities are possible. As usual things depend on details. > > The cleanest solution would be to push upstream gpsim to using the current > gtk+extra2. If they can provide such a solution in not too distant future, > upgrading gtk+extra to 2 and waiting with gpsim probably would be best. Sure, this is the best solution. I asked for that on the gpsim-devel list. As soon I get an answer, I'll feedback. Can we wait several days before doing something or should I have to do something immediatly? As latest gpsim cvs compile with the last official version of gtk+extra (2.1.1), gpsim maintener release a new version today. gtk+extra maintener comfirm me that gtk+extra-1.0.0 is gtk1 based and gtk+extra-2.1.1 is gtk2 based. The unofficial version is no more needed. To name these packages, I purpose gtk+extra for the 1.0.0 version and gtk2+extra for the 2.1.1 version. What to do with the current package named gtk+extra-1.1.0 on the cvs? Because it will seems newer than gtk+extra-1.0.0. (In reply to comment #13) > To name these packages, I purpose gtk+extra for the 1.0.0 version and > gtk2+extra for the 2.1.1 version. OK with me. > What to do with the current package named gtk+extra-1.1.0 on the cvs? > Because it will seems newer than gtk+extra-1.0.0. I see 3 approaches: 1. package the official gtk+extra-1.x into gtk+extra and increment this package's epoch. This way, the new gtk+extra package will drive the "inofficial version" out of systems. 2. Ask one of the release managers to remove the already released *rpms. Unfortunately I don't know who is able to do so. 3. Do nothing, and let gtk+extra-1.1 die out (discontinue the package). As it already had been released for devel, this would imply the package would vanish for FC6 (!). However if another package should require gtk+extra-1.x you probably will have to switch to item 1. above. To me, 1. seems to be the cleanest solution. (In reply to comment #14) > (In reply to comment #13) > > To name these packages, I purpose gtk+extra for the 1.0.0 version and > > gtk2+extra for the 2.1.1 version. > OK with me. > > > What to do with the current package named gtk+extra-1.1.0 on the cvs? > > Because it will seems newer than gtk+extra-1.0.0. > I see 3 approaches: > > 1. package the official gtk+extra-1.x into gtk+extra and increment this > package's epoch. This way, the new gtk+extra package will drive the "inofficial > version" out of systems. I never use the Epoch tag. Should I have to put "Epoch: 1" in the spec? Should I have to do the same thing with the gpsim spec because 0.21.4 requires the inofficial gtk+extra package? gpsim version is now 0.21.11. Should I have to get a review request for the gtk2+extra package? Different option:
Put gtk+extra 2.x into package name "gtk+extra" version 2.x, which will
upgrade the existing packages for the unofficial 1.1.0 version.
Is gtk+extra 1.x needed by anything? Or would it be packaged just for
fun/completeness? If so, it could be packaged as gtk+extra1 any time.
Just make sure that it doesn't conflict _if_ it were packaged.
> Should I have to do the same thing with the gpsim spec
> because 0.21.4 requires the inofficial gtk+extra package?
No. You would build the new gpsim version against your latest
gtk+extra packages, and it would be seen as an upgrade. Mind you,
dependencies on the new/different gtk+extra SONAMES are automatic.
(In reply to comment #16) > Different option: > > Put gtk+extra 2.x into package name "gtk+extra" version 2.x, which will > upgrade the existing packages for the unofficial 1.1.0 version. > > Is gtk+extra 1.x needed by anything? Not in Fedora at the moment, since that's me that want to introduce it because it was needed by gpsim (for previous releases). > Or would it be packaged just for > fun/completeness? I just listened Ralf. > If so, it could be packaged as gtk+extra1 any time. > Just make sure that it doesn't conflict _if_ it were packaged. No conflict. Both are currently installed on my box. > > Should I have to do the same thing with the gpsim spec > > because 0.21.4 requires the inofficial gtk+extra package? > > No. You would build the new gpsim version against your latest > gtk+extra packages, and it would be seen as an upgrade. Mind you, > dependencies on the new/different gtk+extra SONAMES are automatic. OK. Package Change Request ====================== Package Name: gpsim Updated Fedora Owners: alain.portal Please, add my home email in comps because I'm on vacation for 6 weeks. added Package Change Request ====================== Package Name: gpsim New Branches: EL-5 Owners: rrankin CVS done. Package Change Request ====================== Package Name: gtk+extra New Branches: EL-5 Owners: rrankin Note: gtk+extra is required to build gpsim and I cannot find a separate review request for gtk+extra which has been in Fedora since FC-3. cvs done. Package Change Request ====================== Package Name: gtk+extra New Branches: EL-6 Owners: rrankin Note: gtk+extra is required to build gpsim, which already has a CVS tag in El-6, and I cannot find a separate review request for gtk+extra which has been in Fedora since FC-3 and is in EL-5 CVS done (by process-cvs-requests.py). Package Change Request ====================== Package Name: gpsim New Branches: EPEL-7 Owners: rrankin Note; already in EPEL-5 EPEL-6 and Fedora Package Change Request ====================== Package Name: gtk+extra New Branches: EPEL-7 Owners: rrankin Note: gtk+extra is required to build gpsim and I cannot find a separate review request for gtk+extra which has been in Fedora since FC-3 and is in EL-5, EL-6 Git done (by process-git-requests). |