Red Hat Bugzilla – Bug 478950
publican should generate srpm packages without product version number
Last modified: 2010-11-23 23:19:00 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
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.
Created attachment 330170 [details]
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.
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.
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.
(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.
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.
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.
Ok I have a preliminary patch for publican that should allow srpm packages created by publican to play well with Fedora and RHEL.
Created attachment 339978 [details]
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.
Created attachment 340456 [details]
Here is a tested patch which seems to work ok.
Test package is available here:
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.)
(In reply to comment #9)
> Created an attachment (id=340456) [details]
> 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.
(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.
Created attachment 342060 [details]
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.
This is a test package with the above patch:
Created attachment 345058 [details]
I had missed a couple of "-web"'s in the web-brew and web-brew-scratch targets.
Successful web-brew-scratch-en-US build:
Could you please review? :)
Created attachment 345060 [details]
Ok one more iteration.
This now builds in koji too:
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:
saving this for post QA run.
I think this is "fixed" in Publican 1.0.
This should be fixed in the BETA.
]$ publican package --help
Package a language for shipping
--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
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
When is 1.0 going into fedora?
> $ publican package --lang=en-US --short_sighted --desktop
How about calling the option something like "--unversioned".
(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".
We should talk.
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:
publican-1.2-0.fc12 has been submitted as an update for Fedora 12.
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.
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.