Re: Publican Issues for RNs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: pgpxpTA3gRDC6.pgp
Description: PGP signature

-- 
fedora-docs-list mailing list
fedora-docs-list@xxxxxxxxxx
To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-docs-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux