Hi, On 09/28/2012 01:05 AM, Игорь Пашев wrote: > Why not just do GCC docs in a way similar to GNU Make? > Separately build docs from separate source package, and upload to non-free? > (with regular package names)
It's in a similar way to GNU Make indeed. The only difference is more than one version of GCC are supported at the same time, so gcc-defaults and gcc-doc-defaults contain symlinks to the default versions. As packaging work in our git repos[1,2] are gerenerally completed, there're a few todos: 1. Remove gcc-doc-base from gcc-4.4-doc-non-dfsg (already in sid) and gcc-4.6-doc (only in debian/4.6 git branch) package. 2. Upload gcc-4.6-doc and gcc-4.7-doc to sid, at the same time upload new gcc-doc-defaults to point to 4.7. Or better, if gcc-defaults can generate gcc-doc/cpp-doc/... packages again, much work will be saved. [1] https://github.com/SamB/debian-gcc-doc [2] git://git.debian.org/users/yixuan-guest/gcc-doc.git Regards, Guo Yixuan > 2012/9/27 Guo Yixuan <culu....@gmail.com>: >> On 02/15/2012 04:02 AM, Samuel Bronson wrote: >>> On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson <naes...@gmail.com> wrote: >>>> On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko <yo...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5065015c.80...@gmail.com
