Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=476471 Jens Petersen <petersen@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(petersen@xxxxxxxx | |om) | --- Comment #67 from Jens Petersen <petersen@xxxxxxxxxx> 2009-04-14 12:34:36 EDT --- https://fedoraproject.org/wiki/Packaging:Minutes/20090331 contains the full discussion - note FPC explicitly expressed the hope that Fedora releases would not be flooded for multiple versions of every publican manual, unless it is really useful but deferred the individual decisions and burden to the Fedora Docs Project. (For the record: I am disappointed that it was decided to push these two changes into Fedora Packaging Guidelines rather than fix the real problems in publican, but nevermind: embedding desktop files in spec files is also generally a bad idea since it basically make them hard to translate.) So back to my questions in comment 59: * what package are we reviewing here: fedora-security-guide or fedora-security-guide-11? Note there is nothing to stop a fedora-security-guide.src source package from generating a fedora-security-guide-11.noarch binary package, though I don't recommend that personally. If you go for the later base package name than you will have to do a new package review for every release, and how are you planning to deal with OS package upgrades? The versioned package should really obsolete the old package so that the new package will get installed on upgrades. Hence making such parallel installs pretty useless: since rpm does not play well with parallel installs of packages that obsolete each other. In this sense Fedora is a very different OS from RHEL. Parallel packages is going to create a lot more work and packaging complexity - I warn you now here - it has already been well tried and is know (also from my personal experience) not to work well for RPM systems anyway. I fear the approach may be building on sand or thin ice. What you probably want and I would recommend is a base package called fedora-security-guide and then if you really want other version back or forward ported to a release they would be separate packages called fedora-security-guide-F10, etc, as Spot also suggested. In practice I am skeptical if it would really be useful for this particular guide. Also the kernel package for example is capable of parallel installs - in principle there is no reason why different versions of publican packages could not parallel installed too under the same name. Things are worse than that though if you read the above FPC meeting log they further were opposed to individual publican packages per language (though I am not personally opposed to this) they believe there should be one big package with all the translations and then just subpackages for all the language. While this would simplify the base package naming we know this is a bottleneck for building translations of manuals. So taking that into account my overall recommendation at this early stage of fedora publican packaging is just to go with fedora-security-guide-en_US.spec and fedora-security-guide-en_US.noarch. I don't see any win in including the OS version in the package names currently for fedora. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review