It works perfectly well and since the automated RPM creation is not fedora specific I won't be jumping through hoops for the retarded stuff.

(In reply to comment #1)
> It works perfectly well and since the automated RPM creation is not fedora
> specific I won't be jumping through hoops for the retarded stuff.

That won't work.  Fedora packaging standards *are* Red Hat Enterprise Linux standards.  If you expect Publican to produce RPMs that are consumed by Fedora and RHEL, you need to create an srpm that can make a Fedora compliant RPM.

(In reply to comment #2)
> (In reply to comment #1)
> > It works perfectly well and since the automated RPM creation is not fedora
> > specific I won't be jumping through hoops for the retarded stuff.
> 
> That won't work.  Fedora packaging standards *are* Red Hat Enterprise Linux
> standards.

Clearly not true. There are well over 200 packages brewed and ready to ship in RHN right now that are built using this process.

>  If you expect Publican to produce RPMs that are consumed by Fedora
> and RHEL, you need to create an srpm that can make a Fedora compliant RPM.

Red Hat is not fedora cuts both ways; I am in no way constrained in what I can ship in RHEL by what goes on in fedora.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > It works perfectly well and since the automated RPM creation is not fedora
> > > specific I won't be jumping through hoops for the retarded stuff.
> > 
> > That won't work.  Fedora packaging standards *are* Red Hat Enterprise Linux
> > standards.
> 
> Clearly not true. There are well over 200 packages brewed and ready to ship in
> RHN right now that are built using this process.

Just because packages got a pass on the standard does not mean that it is right they continue to be non-standard.  Even more so, it does not make it right to continue to make non-standard packages.

> >  If you expect Publican to produce RPMs that are consumed by Fedora
> > and RHEL, you need to create an srpm that can make a Fedora compliant RPM.
> 
> Red Hat is not fedora cuts both ways; I am in no way constrained in what I can
> ship in RHEL by what goes on in fedora.

If your intention is to develop software that the Fedora community cannot use, then go ahead and do whatever you want.

The problem here is that we cannot use Publican for any of the content for Fedora 11 if it cannot build RPMs that build from source. If the SRPMs created by Publican do not comply with the Fedora standards and make koji choke and die, then the RPMs cannot be built from source.  Fedora building itself is an important design requirement.

This content is:

Fedora Release Notes
Fedora Installation Guide
Fedora User Guide
Fedora Security Guide
Fedora SELinux Guide

We've tried for two releases to use Publican for documentation, and have had to pull the feature twice.  Is being part of Fedora and used to make Fedora (the upstream for RHEL) a goal for Publican or not?

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > It works perfectly well and since the automated RPM creation is not fedora
> > > > specific I won't be jumping through hoops for the retarded stuff.
> > > 
> > > That won't work.  Fedora packaging standards *are* Red Hat Enterprise Linux
> > > standards.
> > 
> > Clearly not true. There are well over 200 packages brewed and ready to ship in
> > RHN right now that are built using this process.
> 
> Just because packages got a pass on the standard does not mean that it is right
> they continue to be non-standard.  Even more so, it does not make it right to
> continue to make non-standard packages.

Just because a package is non standard on fedora does not mean it is non standard on RHEL.

I have seen no notice from any engineering manager that they have ceded control over RHEL packaging standards to fedora packaging, I'm sure they will be interested to learn that you are saying they have.

> > >  If you expect Publican to produce RPMs that are consumed by Fedora
> > > and RHEL, you need to create an srpm that can make a Fedora compliant RPM.
> > 
> > Red Hat is not fedora cuts both ways; I am in no way constrained in what I can
> > ship in RHEL by what goes on in fedora.
> 
> If your intention is to develop software that the Fedora community cannot use,
> then go ahead and do whatever you want.

The fedora community can already use publican, the availability of any individual non-core feature does not affect this.

> The problem here is that we cannot use Publican for any of the content for
> Fedora 11 if it cannot build RPMs that build from source.

What other systems allow people to automatically build fedora compatible documentation SRPMS from source?

Since you have a total of one docs package in fedora, the release notes, and since that is not automated, and would not pass the current packaging idiocy anyway, I can only guess there isn't one.

> If the SRPMs created
> by Publican do not comply with the Fedora standards and make koji choke and
> die, then the RPMs cannot be built from source.

Setting requirements for publican that far exceed what other systems are capable of is ridiculous.

Expanding issues from one of following questionable rules of form over function, to suggestions of functional breakage, is immensely disingenuous.

If you don't like the spec files publican spits out there is nothing stopping you from taking it an changing to suit your needs or writing your own from scratch. This is how all packaging is done outside publican. The fact that we offer a service that caters well for some users is no constraint that we have to support that usage for all users.

It's laughable to suggest this feature is critical to using publican when publican is clearly superior in many way to your current tool chain. There is no other tool chain that gets anywhere near this close to allowing authors to package their documentation with such little effort.

>  Fedora building itself is an
> important design requirement.

The SRPMs build in Koji and install/upgarde/uninstall perfectly. They have been thoroughly tested by Red Hat QE. There is no technical problem with them.

Insisting packaging has to be automated is an exceptionally high requirement that is not met by any other system, documentation related or not.

> This content is:
> 
> Fedora Release Notes
> Fedora Installation Guide
> Fedora User Guide
> Fedora Security Guide
> Fedora SELinux Guide
> 
> We've tried for two releases to use Publican for documentation, and have had to
> pull the feature twice.

It took a guy who has never seen fedora docs content 20 minutes to port your release notes to publican, there is no technical issue here.

Blaming publican because your translation infrastructure can't handle multiple files, which is necessary for large bodies of content, is, at best, disingenuous.

>  Is being part of Fedora and used to make Fedora (the
> upstream for RHEL) a goal for Publican or not?

Publican is already part of fedora, that's why I have been fixing bugs opened by the fedora community for the last 2 fedora releases. I think asking this because I refuse to jump through any more stupid hoops related to fedora packaging is, yet again, very disingenuous.

Jeff, I can't tell whether you would take a patch to improve this or not. Would you?

(In reply to comment #6)
> Jeff, I can't tell whether you would take a patch to improve this or not. Would
> you?

I'm happy to accept patches from anyone for anything.

I might be able to contribute a patch at some point - but just to note that FPC and FESCO approved the option now to allow embedded .desktop files now though separate one is still preferred for Fedora since it is easier to translate, etc, which eases the situation.

Given that publican srpms are generally generated directly by publican I don't think this is that important really or matters that much.

The only question is really how do you plan to localize the .desktop files for translated books if it is not already done?

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

Policy has been changed to allow the desktop file to be created at build time.