Red Hat Bugzilla – Full Text Bug Listing
|Summary:||publican should generate srpm packages without product version number|
|Product:||[Community] Publican||Reporter:||eric <eric>|
|Component:||publican||Assignee:||Ruediger Landmann <rlandman>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||1.6||CC:||anross, jfearn, mhideo, mmcallis, petersen, publican-list, r.landmann|
|Fixed In Version:||1.2-0.fc12||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-11-20 00:20:49 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description firstname.lastname@example.org 2009-01-06 02:29:18 EST
Description of problem: The document I'm working with isn't for a specific version of fedora so the publication number is set to "." which shows up everywhere. I think when you use the "." then it should keep that field from showing up. Right now my document shows up as Fedora .: Linux Security Guide and the SRPM shows up as fedora-Linux_Security_Guide-.-en-US-1.0-5.src.rpm. Version-Release number of selected component (if applicable): 0.39-0.fc10
Comment 1 email@example.com 2009-01-20 10:19:38 EST
If it is possible to have Publican omit the publication number from the package name that would be most helpful. It does not conform with the Fedora naming scheme.
Comment 2 firstname.lastname@example.org 2009-01-27 17:48:19 EST
Created attachment 330170 [details] Possible patch. This works for me but will also change the process for ALL users. I'm sure this is not the optimum solution but I'm not gifted enough to fix this the proper way.
Comment 3 Jeff Fearn 2009-01-27 21:30:50 EST
This patch breaks the intended functionality of this feature, which is to enable documentation for multiple versions of a product to be installed on a users desktop. This allows people maintaining multiple versions of a product to have access to the documentation on the one machine instead of having to have multiple machines to access content on. e.g. if you are a sys-admin maintaining a network of computers containing several versions of fedora, then you can access the documentation for all the versions of fedora you are maintaining on your workstation instead of having to go to a machine with a particular version of fedora on it to read the documentation. Removing the product version from the tar name breaks this functionality. This naming scheme does not breach any DOCUMENTED fedora naming scheme.
Comment 4 email@example.com 2009-01-27 22:01:39 EST
Well, this is one of the things my reviewer is complaining about. There should be a way to not have to use it if you aren't planning on maintaining multiple versions of a product. The way it is designed now you HAVE to use multiple versions.
Comment 5 Jeff Fearn 2009-01-27 22:34:49 EST
(In reply to comment #4) > Well, this is one of the things my reviewer is complaining about. Which is why I've stopped packaging things for fedora, it's really not worth the headache. > There should be a way to not have to use it if you aren't planning on > maintaining multiple versions of a product. The way it is designed now you > HAVE to use multiple versions. It requires that you specify a version, there is nothing forcing you to maintain more than 1 version. You could set it to 0 and never change it. This same naming scheme is used to produce the web site payload, which _really_ requires being able to handle multiple product versions, so to enable non-versioned rpms would require separate make targets. Part of this limitation is due to the complexity of the Makefiles; they really need to be ported to a programming language but I can't get time allocated to that atm. see: https://bugzilla.redhat.com/show_bug.cgi?id=471703 The packaging functionality works as intended, with all the limitations that entails, and I can't see time being spent in the near future on adding an additional packaging work flow.
Comment 6 firstname.lastname@example.org 2009-01-27 22:44:08 EST
Yeah, when I "broke" it I was pretty sure you couldn't do it two different ways at that particular point. I wasn't for sure, though.
Comment 7 Jens Petersen 2009-04-17 05:56:00 EDT
Ok I have a preliminary patch for publican that should allow srpm packages created by publican to play well with Fedora and RHEL.
Comment 8 Jens Petersen 2009-04-17 06:02:29 EDT
Created attachment 339978 [details] publican-srpm-naming.patch This is a first take at improving the rpm package naming scheme: needs testing and feedback. I will submit to upstream for review once we think it looks ok. I can provide test a rpm package.
Comment 9 Jens Petersen 2009-04-20 20:07:03 EDT
Created attachment 340456 [details] publican-naming-take4.patch Here is a tested patch which seems to work ok.
Comment 10 Jens Petersen 2009-04-20 20:12:10 EDT
Test package is available here: http://petersen.fedorapeople.org/publican/publican-0.45-0.2+naming.fc11.noarch.rpm Please test when you have a chance. (ps Also want to add make targets for koji to allow Fedora writers to push builds straight to koji like Red Hat writers can to brew.)
Comment 11 Jeff Fearn 2009-04-28 21:43:06 EDT
(In reply to comment #9) > Created an attachment (id=340456) [details] > publican-naming-take4.patch > > Here is a tested patch which seems to work ok. As per comment #3 this patch breaks the intended functionality of this feature, any distro specific changes for package naming must be constructed in such a way that the default behaviour is _not_ changed. The cleanest way to do this would be to add new build targets, but it could also be achieved by adding new variables to allow this change to be enabled, which would default off, and introducing if statements in to the existing build targets.
Comment 12 Jens Petersen 2009-04-29 03:15:35 EDT
(In reply to comment #11) > The cleanest way to do this would be to add new build targets Ok agreed then I will try to rework the patch for that.
Comment 13 Jens Petersen 2009-05-01 05:28:07 EDT
Created attachment 342060 [details] publican-naming-take5.patch Ok, here is a reworked patch which adds a fedora-spec.xsl to generate a spec for fedora, and also provide koji build targets. It should preserve the naming of all the current srpm and rpm packages (srpm-*, brew-*, web-*, etc). I tested it a bit and it looks ok to me.
Comment 14 Jens Petersen 2009-05-01 05:35:56 EDT
This is a test package with the above patch: http://petersen.fedorapeople.org/publican/publican-doc-0.45-0.4+naming.fc11.noarch.rpm
Comment 15 Jens Petersen 2009-05-01 05:36:35 EDT
Comment 16 Jens Petersen 2009-05-22 01:12:24 EDT
Created attachment 345058 [details] publican-naming-take6.patch I had missed a couple of "-web"'s in the web-brew and web-brew-scratch targets. Successful web-brew-scratch-en-US build: https://brewweb.devel.redhat.com/taskinfo?taskID=1811521 Could you please review? :)
Comment 17 Jens Petersen 2009-05-22 01:16:09 EDT
Comment 18 Jens Petersen 2009-05-22 02:19:32 EDT
Created attachment 345060 [details] publican-naming-take7.patch Ok one more iteration. This now builds in koji too: http://koji.fedoraproject.org/koji/taskinfo?taskID=1369751 http://petersen.fedorapeople.org/publican/publican-0.45-0.7+fedora.fc10.noarch.rpm
Comment 19 Bug Zapper 2009-06-09 06:36:12 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Michael Hideo 2009-06-16 22:32:20 EDT
saving this for post QA run.
Comment 21 email@example.com 2009-08-05 15:03:30 EDT
I think this is "fixed" in Publican 1.0.
Comment 22 Jeff Fearn 2009-08-10 19:29:17 EDT
This should be fixed in the BETA. ]$ publican package --help package Package a language for shipping Options: --lang=<LANG> The language the XML will be written in --desktop Create desktop instead of web package --brew Push SRPM to brew --scratch Use scratch instead of tag build. --short_sighted Create package without using version in package name --binary Build binary RPM when running package
Comment 23 Ruediger Landmann 2009-09-08 19:49:58 EDT
Fixed in 1.0: $ publican package --lang=en-US --desktop ... $ Wrote: /home/rlandmann/Documents/beta/readme-live-image/tmp/rpm/Fedora-Fedora_Live_images-11-en-US-1-1.el5.src.rpm $ publican package --lang=en-US --short_sighted --desktop ... $ Wrote: /home/rlandmann/Documents/beta/readme-live-image/tmp/rpm/Fedora-Fedora_Live_images-en-US-1-1.el5.src.rpm
Comment 24 Jens Petersen 2009-09-20 21:55:07 EDT
When is 1.0 going into fedora?
Comment 25 Jens Petersen 2009-09-20 22:10:11 EDT
> $ publican package --lang=en-US --short_sighted --desktop How about calling the option something like "--unversioned".
Comment 26 Jeff Fearn 2009-09-20 22:19:09 EDT
(In reply to comment #24) > When is 1.0 going into fedora? When it's done. (In reply to comment #25) > > $ publican package --lang=en-US --short_sighted --desktop > > How about calling the option something like "--unversioned". No.
Comment 27 Jens Petersen 2009-09-21 22:57:00 EDT
We should talk.
Comment 28 Bug Zapper 2009-11-16 04:45:30 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 29 Fedora Update System 2009-11-17 21:19:39 EST
publican-1.2-0.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/publican-1.2-0.fc12
Comment 30 Fedora Update System 2009-11-20 00:18:51 EST
publican-1.2-0.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Comment 31 Fedora Update System 2009-11-25 09:53:56 EST
publican-1.2-0.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.