Re: RFS: linsmith
On Fri, Nov 04, 2005 at 05:36:21PM -0300, Margarita Manterola wrote:
> > Description: a program to make Smith Charts
> > I would suggest "a tool to generate Smith Charts", since most of
> > Debian is "program", for at least somebody's definition of program.
>
> Well, that goes almost as much for "tool". But I can change it, I
> don't really mind.
Even just "Smith Charts generator", maybe.
> > Long description:
> > I would suggest explaining what a Smith Chart is somewhere other than
> > the first sentence, which should be specific to this tool. See the
> > Developers Reference for such best practices.
>
> Well, this was changed in reply to my ITP since people got confused by
> the fact that they didn't know what a Smith Chart was. I do feel it
> makes much more sense to put the explanation first and then the
> description of what the tool does. Than to explain what the tool does
> and the suddently explain what a Smith Chart is.
My motivation in writing that was Devref 6.2.3:
The first paragraph of the long description should answer the
following questions: what does the package do? what task does it
help the user accomplish? It is important to describe this in a
non-technical way, unless of course the audience for the package is
necessarily technical.
Here, you're describing what it does to someone whos interested in
smith charts, because thats what the short description is.
> > > ./debian/linsmith.doc-base:
> > The abstract should include some technical detail.
>
> There isn't much technical detail to give. It's a user manual, with
> screenshots and stuff.
Well, it doesn't make sense for every doc-base abstract in Debian to
say the same thing.
> > ./debian/rules:
> > You might consider including the list of documentation on the
> > commandline for dh_installdocs, rather than in a separate file.
> > Same for dh_installdirs.
>
> I like the separate files way.
Okay; to each his own.
> What would I gain by having it in the rules file?
I don't like lots of little files. Separate files are okay if they
are big, but IMHO it is easier to maintain a single rules file which
determines the build as fully as possible.
> > You might also consider *removing* config.{sub,guess} in the clean
> > target, rather than copying them. This makes the .diff easy to read,
> > which is important IMHO. Then you will want to copy or symlink them
> > somewhere in the configure target (or a dependency thereof).
>
> This is the dh_make template. If you are sure that your approach is
> better, I suggest you file a bug against it.
There are differences in opinion. A readable diff is more important
to me than having orig+diff be a constant thing.
Other people may find otherwise..
> > So, the only big problem is that PDF file. You will want to generate
> > it from source, which will make the .diff much smaller, and also means
> > that the source is actually included, and the generated files are
> > actually generated by building. Remember to update build-deps as
> > necessary.
>
> The source IS included, the file is pre-generated because it doesn't
> make sense to do it at build time.
s/doesn't make sense/seems to be impossible/
> I did not choose to uuencode and uudecode it just because I'm crazy,
> it's the solution to the problem posed by having to generate the
> file from a lyx source.
The need for uuencode is caused by the fact that dpkg-source -b will
error on binary files; otherwise you could just use the .pdf.
--
Clear skies,
Justin
Reply to: