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

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

> > I will try to look sometime soon, but can't promise when.

Hello Samuel

The gcc-doc thing you've done looks great, however it is incomplete.

Complete solution consists of gcc-doc-defaults package [contrib], and 
several gcc-X.Y.doc-non-dfsg [non-free], that all must match each other. 
There should be gcc-X.Y.doc-non-dfsg for each gcc-X.Y that is in debian 
main, and only one of those must provide gcc-doc-base package.

Upload must be done for all components in sync (perhaps together with 
filing RM requests for obsolete source packages). Uploading only part of 
these will leave things in broken state. E.g. several source packages will 
provide gcc-doc-base binary package, or gcc-doc-defaults will provide 
packages with broken depends and/or symlinks.

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 

Could you please clone these repos, and reformat your work into this 
IMO this format greatly helps to keep things consistent.

Maybe this could be moved to git.debian.org.

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/ 

Also, if you convert to 3.0 (quilt), why still mentioning dpatch in 

*) 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?

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.

*) [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 :).

> 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 


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: