Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko <yoush@debian.org> wrote:
>> > 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.
I see.
> 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!
> 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?
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.)
> Also, if you convert to 3.0 (quilt), why still mentioning dpatch in
> README.source?
That was an accident.
> *) 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:
* Take the debian/ directory from "gcc-X.Y", post-processing the
> *) [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!
Reply to: