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

Re: Packaging Barcode Writer in Pure PostScript



On Tue, Sep 06, 2005 at 09:53:51AM +0100, Terry Burton wrote:
> Hi,

Hello,

> Would people please examine the package and tell me what problems
> exist. You can view the files at
> http://www.terryburton.co.uk/barcodewriter/files/debiansrc

After a very brief look, I can only say I saw a lot of commented out lines in
rules.make.  I guess they come from dh_make.  There's no need to leave them
in, just remove them.

> Some additional questions:
> 
> The project has no dependancies. Is it safe to remove this line from
> the control file?
> Depends: ${shlibs:Depends}, ${misc:Depends}

A follow-up to that question: ${misc:Depends} gives "undefined variable" (or
something) warnings on some of my packages.  Should I remove them from those,
or is it good to leave them in in case something will be substituted in there
later?  Where would the content come from anyway?

> The upstream project unpacks all files into a single directory and
> does not provide a facility for installing the files into a distro's
> file system hierarchy. For the Debian package I have created a
> Makefile that accomplishes his via the install target. There is no
> compilation necessary so I have created empty all and clean targets.
> Could somebody verify that this is the correct way to handle such a
> package.

Personally, I would just use debian/rules for that.  There is a step to build
(which will be empty in this case) and one to install, which will be like
cp --parents files debian/tmp/somedir/.

> Debian Policy mandates that programs have a manpage. Since this is a
> PostScript resource (similar to a shared library) does this rule still
> apply. If so then I'm not sure what the content of such a manpage
> ought to be.

Policy mandates manpages for executables.  This is not one of them, I guess.
However, it is good to create one anyway if the user can directly use the
file.  That is, if it is only used by other programs (as is the case for a
shared library), there is no need for a manpage.  If you expect the user to
use the files in the package directly, a man page is in order IMO.  In it
should be a manual describing what the user could do with it.  In other words,
after reading the man page, the user should be able to use the package.

> The project is platform independant as specified in the control file.

No, you specified "Architecture: any" in the control file, which means it is
portable to all platforms, in other words that it can be compiled on each of
them.  "Architecture: all" means it's platform independant.

> After I have got the source package into good shape, do you have any
> advise on finding a package sponser? Any volunteers.

I'm not a DD yet, so I can't help you there.

Bye,
Bas Wijnen

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: