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_...
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