Re: Fwd: RFS: gcc-4.5-doc-non-dfsg

[Guo Yixuan <culu.gyx@gmail.com>]

Hi,

On 02/15/2012 04:02 AM, Samuel Bronson wrote:
> On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson <naesten@gmail.com> wrote:
>> On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko <yoush@debian.org> wrote:
> 
>>> In good old days when I had time and motivation to maintain gcc-doc, I've
>>> used git repos to managed entire thing.
>>> I've just created externally-available mirror for those - please check
>>> http://yoush.homelinux.org:8079/git
>>>
>>> Could you please clone these repos, and reformat your work into this
>>> format?
>>> IMO this format greatly helps to keep things consistent.
>>
>> I can certainly try!
> 
> Okay, I've cloned your gcc-doc repository and added my changes:
> 
>     git clone https://github.com/SamB/debian-gcc-doc
> 
> (Or open it in your browser, or ...)
> 
> I'm holding off on updating the 4.4 control files and the -defaults
> packages for the moment: I want to streamline the "new X.Y" process a
> bit more first.
> 
>>> Maybe this could be moved to git.debian.org.
> 
> Yes, that sounds like a good idea. Then I could add the Vcs-*: fields
> to debian/control. Of course, there will probably be a lot to update
> in README.source then...
> 
>>> As for the rest, here are several more comments:
>>>
>>> *) I don't really understand the workflow of gcc-doc-non-dfgs converted to
>>> 3.0 (quilt) format.
>>>
>>> With old format, there was debian/patches, managed by dpatch, with part of
>>> patches managed by hands, and part managed by a perl script. Running the
>>> script altered debian/patches/* files, including series file. But isn't
>>> this unsafe for 3.0 (quilt) format since it will break metadata in .pc/
>>> directory?
>>
>> Hmm. Perhaps the script should simply refuse to run whenever there is
>> a .pc directory? (It seems that dpkg-source removes this after
>> unapplying the patches.)
> 
> In any case, most of this is changed very little; the script just gets
> to be a bit shorter since the patches no longer have to be shell
> scripts.
> 
>>> Also, if you convert to 3.0 (quilt), why still mentioning dpatch in
>>> README.source?
>>
>> That was an accident.
> 
> I've corrected this now.
> 
>>> *) Looks like your command line for patch convertion script is much shorter
>>> that in was in previous times. How did you check which patches to apply
>>> and which not?
>>
>> Well, I grepped the GCC package's debian/patches for anything that
>> changed .texi files, and looked through the debian/rules.patch to see
>> which of those seemed to be applied for Debian builds on any
>> architecture (in that alternate universe where
>> GFDL_INVARIANT_FREE=no).
>>
>>> Actually I've looked at updating gcc-doc during new year holidays, and
>>> stopped and postponed it exactly at this point. It was unclear what
>>> patches to apply, looked like some procedure/policy was needed, and I
>>> could not think your such a policy at that time.
>>>
>>> The idea was to check what patches are applied for each of in-debian
>>> architectures, and apply doc changes for all of those. This could likey be
>>> automated, e.g. by writing a makefile that will include debian/rules2 from
>>> gcc package, and then use vars set by that to print list of applied
>>> patches; some tricks with var-setting could do this for all archs.
>>
>> Hmm, not a terrible idea.  I still think the *very* cleanest thing
>> would probably be to build "gcc-X.Y-doc-non-dfsg" like this, though:
> 
> [Oops, I forgot to finish this bit:]
> 
>  * Take the debian/ directory from "gcc-X.Y"
>    + uncomment the documentation patches if necessary
>    + replace debian/control with one that only builds the documentation packages
>    + arrange for "GFDL_INVARIANT_FREE=no" to be set
>  * Put a pristine upstream tarball in the root of the tree in place of
> the stripped one that gcc-X.Y uses.
> 
> (Of course, this would turn the package into little more than a script
> to generate the *actual* packages.)
> 
> However, as I'm always low on diskspace, I'm a bit reluctant to
> actually *try* this.
> 
>>> *) [minor but still] it looks a bit unfair that there is only your
>>> signature under README.source, while large part of the text was written by
>>> me :).
>>
>> I agree with you that this was a very rude of the README.Debian Emacs
>> mode to do this. I can understand updating the date; removing your
>> name, not so much. Though, it also obviously shouldn't simply update
>> the date next to your name. So I'm not really sure what it *should*
>> do...
>>
>> If you can think what it should do, maybe we should open a bug against
>> /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the
>> change?
>>
>>>> 2. In contemplating putting debian/copyright in DEP-5 format, I've
>>>> realized that I'm not sure of the exact copyright/licensing status of
>>>> anything in the debian/ directory, except:
>>>
>>> See debian/copyright from the old packages. Everything non-autogenerated
>>> under debian/ was stated to be GPL;  I don't object changing that if
>>> needed.
>>
>> No, there's certainly no need to change that. (Of course, I would not
>> object if they were to be put under the Expat license. :-)
>>
>> P.S.  I apologize for returning the slow response time!
> 
> I've now actually made an attempt at putting debian/copyright in DEP5
> form. There are a couple of holes in it still, but that's mostly
> because of upstream problems, and the holes have been there all along
> anyway.
> 

How's it going now? Samuel has done much work in packaging
gcc-4.[67]-doc, while there doesn't appear to be any real uploads.

I've updated debian/4.7 branch in my personal git repo at Alioth, you
can check it out:

  git clone git://git.debian.org/users/yixuan-guest/gcc-doc.git

Regards,

Guo Yixuan