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

Re: RFS: Looking for a mentor for my dspdfviewer package



On 05/08/15 16:15, Gianfranco Costamagna wrote:
> 
> nope, the manpage is correct, I tried a --help, and I didn't find it
> (sorry for the confusion)
> 
>> If you have a suggestion on where to place and/or how to re-word the
>> manpage, that would be much appreciated. Since I'm more a developer than
>> a user (and I know the software inside out anyway) its difficult for me
>> to think from a user perspective.
> 
> 
> that is something always difficult... Maybe the --help can be more similar to the 
> good manpage? :)

Right now, --help is simply boost_program_options' default output, which
I find pretty nice, especially considering how few option-parsing and
help-outputting lines of code I actually had to generate myself.

I will add a sentence stating that interactive keybinds are stated in
the manpage.

For me it feels natural that a program only tells me
--command-line-switches on --help, and I will find the rest in the
manpage, but an additional pointer can't hurt. The only thing I'd like
to avoid is more duplication between --help, man dspdfviewer and website
(since  one of them always forgets to get updated, and thanks to Murphy,
that's the only one the user did read : )


> lintian -EvIL +pedantic --profile debian/main ../dspdfviewer_1.13-1_amd64.changes
> 
The EvIL pedantic lintian. Shell-aliased to lint now : )


> 
> 
> they are always suggestions, so feel free to leave it if you think users might benefit
> (what about creating a -dbg package? since it is a new package you might benefit from one
> trip only in the NEW queue)
> 

I have never created a -dbg package, but if that helps Debian-users to
generate meaningful backtraces -- Who could say no to that : )

I'll revise the source package and work in the -dbg stances.


> 
> This is equivalent actually for Debian (it will allow you to remove 6 lines from the CMakeFile),
> but it might be a problem for other Linux based Distro around the globe.

Right now, I'm thinking about renaming the env-variable from
DEBIAN_PACKAGE_VERSION to DISTRIBUTION_PACKAGE_VERSION or something
similar to be "cross-distribution", and nicely ask the maintainers of
$dist to add some dist-specific postfix to it (I know gentoo has -r1) if
they changed any source files.

But i guess for now we can use debian/rules to (always) enter if@71.

> 
> Having one single way to feed the version might be a benefit for everybody
> 

v1.14 will have that most likely (less cruft wins) : )


> BTW the new rules file is what I intended previously, and makes lines 91:96 useless now :)
> 
> (not asking you to remove, just pointing that to you).
> 
> Last thing:
> 
> d/rules, lines 2 to 8, I guess you can remove them
> 

I will. Just seemed like a boilerplate "keep it in there", but since it
says itself "without restrictions" I guess it's best to delete
boilerplate comments so you only have to read the ones actually from me.

> let me know about the last two things (specially for the dbg package, that is something important)
> and I'll do the upload

I will make the dbg package (didnt know about that), so please don't
upload just yet.

I won't have it ready today, expect a revised package tomorrow.

-- 
Cheers,

Danny


Reply to: