[LAD] Build and get your package in Debian/ Ubuntu (was Re: [LAU] Join the Debian Multimedia Team! (to improve the state of Linux audio))

[Grammostola Rosea]

Hans Fugal wrote:
> Grammostola Rosea wrote:
>
>   
>> Changed the title, cause it's an important discussion opened by Fraser imo.
>>
>> \r
>>     
>
> I think it is, too. I've maintained a few Debain packages in the past
> (don't have time at the moment), so I can weigh in.
>
> The documentation is out there, but unless you're an aspiring debian
> maintainer it's not easy to find nor very accessible. It's a pity,
> because there are a few things you can do as an upstream author to make
> debian packaging really simple, and it's not rocket science.
>
> I'm going from memory here, but I think these are the most important
> things you can do:
>
> 1. Make it easy to install to an arbitrary location, a la --prefix with
> autotools.
>
> 2. Put stuff in the right places under that prefix (see the FHS or
> section 9.1 of the Debian policy manual).
>
> 3. Documentation - especially man pages which are required for all
> binaries (even if they just refer to online documentation or info
> pages). This requirement is often skipped for Ubuntu-only packages which
> makes me as a user sad. 
Yeah an manpage is required. You can use the app gmanedit for example to 
create one.

> It's also very helpful (for maintainers and
> users alike) if you give a list of dependencies in your README.
>
> 4. Use a sane versioning scheme - one that monotonically increases and
> has the most significant parts first and doesn't use funky characters.
> So, if you base it on a date, 2009-04-01 or 20090401, not 1/4/2009. See
> section 5.6.12 of the debian policy manual.
>
> It can also be especially convenient if you use a distributed version
> control system, esp. git, 
yeah the Debian Multimedia Team uses git, so this is highly preferable imho.

> but a good maintainer should be able to work
> with tarballs or whatever system you use. Encourage the debian
> maintainer to pass along patches or bugs and not keep them to himself,
> and consider keeping the debian/ directory in upstream (in ideal cases
> everything needed for debian packetization is there in debian/ - out of
> the way of non-debian users - and none of your sources need to be patched)
>
> Hope that helps.
>
> 1. http://www.debian.org/doc/debian-policy/
> 2. http://www.pathname.com/fhs/
> 3. http://www.debian.org/doc/maint-guide/
>
>   
Also I got the advise:
/Upstream should switch to autotools or something that does DESTDIR out 
of the box.
(|automake(1)| and/or |autoconf(1) |related issue?)/
see: http://www.debian.org/doc/maint-guide/ch-modify.en.html

Another quote:
/I don't see a difference between adding a (well maintained) debian/ 
directory to someone else's software or to my own, i.e. if you know how 
to make Debian packages out of sources for package foobar, you are also 
able to prepare the packaging for the softeware you wrote yourself. Why 
should this be documented separately? /

Also a clear describtions about the AUTHORS of the app and COPYING 
(copyright of the app and maybe other files etc it uses which are 
copyright by other authors, is very important.

\r