Publican Issues for RNs
Paul W. Frields
stickster at gmail.com
Fri Mar 13 12:42:47 UTC 2009
On Fri, Mar 13, 2009 at 04:49:42PM +1000, Jeff Fearn wrote:
> Paul W. Frields wrote:
>> On Thu, Mar 12, 2009 at 08:57:52AM -0400, John J. McDonough wrote:
>>> Let me preface this by mentioning that I haven't got a clue about packaging,
>>> so assuming I am a complete idiot wouldn't be inappropriate.
>>>
>>> Eric discovered back in January that there are a couple of show stoppers to
>>> using Publican for Docs. He thought he was going to get the issues fixed in
>>> a short time, but that hasn't happened, and it doesn't look like it will
>>> happen. Eric developed a workaround by hacking Publican. Unfortunately,
>>> using this approach would require everyone participating in Docs to have a
>>> hacked Publican, and the hack breaks Publican for other uses. A switch
>>> would be nice, and acceptable to the Publican developers, but apparently it
>>> would take a lot of effort and there is only one maintainer.
>>
>> Can Jeff Fearn or some other knowledgeable person explain here what's
>> needed for that switch? We probably can find some resources for
>> writing that switch, but to do that we need to know what's required.
>
> I haven't looked to deeply in to it. The tar/package name structure is
> use in many of the templates in the common Makefiles and testing having
> two naming methods would require some pretty robust analysis.
>
>>> Publican does almost everything we need to do between the wiki and the RPM,
>>> so we would really like to use it rather than the mish-mash of tools we
>>> currently have.
>>>
>>> There are two problems:
>>> 1) Publican names the package incorrectly
>
> For values of incorrectly that are not in the published fedora package
> naming guidelines AND for values of incorrectly that fail miserably to
> understand the value-add that having access to multiple versions of
> product documentation on your desktop offers.
>
> Being able to review the fedora 11 release notes on fedora 10 while you
> are off line is a valuable feature.
>
> Having access to the admin guides for multiple versions of fedora on your
> desktop is a valuable feature, particularly if you have to support
> multiple versions of fedora. Like say a system administrator.
>
> It only takes a little imagination to see how this benefits being able to
> syndicate content to the desktop. I'm surprised the fedora docs team
> aren't screaming for this feature.
Re: https://bugzilla.redhat.com/show_bug.cgi?id=476471 , I assume.
Don't we have version names in other packages, such as in the case of
compatibility libraries? Like libsoup22, for instance? It seems to
me there's a precedent for this. Added my comment to the bug FWIW.
>>> 2) The .desktop file is handled differently than the reviewers would like
>
> For values of like that ignore compatibility with other distros.
We could simply provide a patch or separate .desktop file, I suppose.
Typically no independent, cross-distro upstream would take a patch
that breaks other distros in favor of Fedora. At the same time,
Fedora standards are against carrying long-term patches, in favor of
working with upstream. If that's an unresolvable conflict, might be a
matter to take to the Packaging committee, if nothing else asking for
them to write an exception into the policy.
>>> Now it seems to me, worst case we could run Publican and then package the
>>> HTMLs manually. But since Publican already does most of the heavy lifting,
>>> why not simply patch Publican's work after the fact.
>>>
>>> To this end, I made an attempt to do the following:
>>> 1) Unpack the SRPM produced by Publican, The SRPM has 2 files, a tarball and
>>> a specfile
>>> 2) Rename the tarball, which involves untarring and retarring it
>>> 3) Edit the specfile
>>> 4) rpmbuild
>>
>> Publican also has a 'make tar-<LANG>' target for making just the tarball.
>
> If you run make spec-<LANG> it will make the spec and the tar.
>
> BTW fedora packaging requires you to check TAR files in to CVS to get
> them built in koji, the srpm is just used for package review, after that
> you have to check the spec and tar file in to CVS, tag it and build it in
> koji. Much of the benefit of getting a source rpm is lost at that point.
> If you can't get a number in a package name I seriously doubt you will be
> allowed to push source rpms in to koji.
Right, but you can do a "cvs-import.sh <SRPM>" to do this, which I
have done repeatedly for previous fedora-release-notes packages.
However, if the built-in .spec or some contents of the .tar aren't
already in the form you want them, that's not going to be
advantageous.
>>> I wrote down the details of what I did at
>>> https://fedoraproject.org/wiki/User:Jjmcd/Drafts/Converting_Publican_RPM_for_Fedora
>
> I thought this was pretty neat, but it's probably easier just to run make
> spec and use the sources in tmp/rpm.
>
>>> When I do this, the resulting RPM passes rpmlint, installs correctly, and
>>> seems to meet the guidelines. What am I missing? Well, appears to install
>>> correctly. A menu entry appears and when I click on it I see release notes.
>>> Maybe there are less obvious things going on.
>>>
>>> As far as the .desktop file, I don't fully understand the issue here. The
>>> code produced by Publican appears to be almost identical to that in the
>>> packaging guidelines on the wiki and very similar to what it is in the
>>> current release notes. David Nally tells me of an entirely different way to
>>> deal with the .desktop file but I don't know enough to understand why it is
>>> better.
>>>
>>> So what I'm asking is:
>>> 1) Is this totally wrong-headed and we should be looking up another avenue
>>> 2) How can this approach be made better
>>> 3) Is there some other way
>>
>> It might be helpful to have David or someone to describe the exact
>> issue with the .desktop file here, or just point us to a bug where we
>> can read about it. I'm looking at Publican to see whether we could
>> add the needed stuff to /usr/share/publican/make/Makefile.fedora,
>> which would keep it in the Fedora brand package and away from where it
>> breaks other things that Red Hat might use internally.
>
> It would mean other brands being used on fedora wouldn't be usable for
> fedora packages.
I see your point.
>> If that ends up being a bad place to put things -- because the
>> Makefile.templates haven't been included yet at that point, perhaps --
>> then it would seem relatively easy to also have the Makefile.common
>> provide:
>>
>> ifeq "$(BRAND_MAKE)" "1"
>> include $(COMMON_CONFIG)/make/Makefile.$(BRAND).post
>> endif
>>
>> After the global templates, and we can craft those targets as needed.
>> I'm not completely Makefile-ignorant, fortunately, after having spent
>> some time working on our FDP toolchain. I'll try to help where I
>> can. If Jeff's willing to take a patch like that, or if he can help
>> me understand where's a better place to put these sorts of
>> customizations, I'm up for writing them. We really do not want to
>> have to punt this again for lack of elbow grease.
>>
>
> We use the double colon for targets, e.g. foo::, so you can't over ride
> them, you can only add pre/post processing to them. You could add new
> targets that depend on old targets or just cut, paste and rename existing
> templates, then change the behaviour.
>
> Really though, by doing this you are removing what is, IMHO, the biggest
> value-add of packaging the docs in the first place, the ability to have a
> library of content at your fingertips. Huge price to pay just to get rid
> of a number.
Yeah, that's clearer to me now.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20090313/2f2379b3/attachment.bin
More information about the docs
mailing list