> > 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 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. 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/ directory? Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? *) 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 needed. Nikita
signature.asc
Description: This is a digitally signed message part.
