[Fwd: Re: [LAD] [LAU] Join the Debian Multimedia Team! (to improve the state of Linux audio)]

[Felipe Sateler]

El 01/04/09 21:16 Grammostola Rosea escribió:
> Hi,
>
> I think Fraser has an point in the message below. Is there documentation
> for Developers to make their apps easy to build for Debian etc. ?
>
> Suggestions?
>
> \r
> From: Fraser <fraser at arkhostings.com>
>   Grammostola Rosea wrote:
> > I suggest add a 'chapter' in the wiki of linuxaudio.org with information
> > about maintaining packages. The information about Debian/Ubuntu you can
> > find in my link. But I can imagine that also other distro's like to
> > write down some information about maintaining multimedia packages, cause
> > it would be nice if we could improve GNU/ Linux audio by getting more
> > packages into the different distro's.
>
> A thought to consider - when I embarked upon creating debian and ubuntu
> packages of my own software, I found very little in the way of guides to
> assist a developer, the guides are focused on maintaining someone else's
> software (often already packaged).

The Debian way of doing things has always been this way. Upstreams are 
discouraged from doing their own packaging, unless they do it separately from 
regular upstream work (ie, release a source tarball, and then do a debian 
package out of that), and they are involved in the debian community. 
Distributing binary packages is not that simple, specially for complicated 
packages which use lots of libraries. In general, it is better to let others 
(if they are available) take care of the process of packaging. 
This is because the process of providing a debian package not only has to do 
with creating a debian dir and populating it, but also to follow debian for 
library transitions or other developments (a binary distribution carries a 
new set of problems than distributing source).

> It can't hurt to educate developers on how to assemble packages for their
> own software, just making them aware of what's required will lead to
> reduced effort to package and the ones who chose to include the debian
> build files in the source shift the maintainer effort to quality control
> type role (hopefully fed back to the developer to include).

In general, upstreams (unless they are already involved in debian development) 
do not need to care about a lot of the stuff debian packagers need to. A huge 
part of policy (the definite rulebook on debian packages) is not relevant for 
upstreams. For example, paths are defined by policy, and you shouldn't have 
to care about that (other than allowing for specifying of these paths at 
build time, which you should be doing anyway).

Debian packagers need to learn/remember a lot of stuff specified by policy. If 
you are willing to learn that, great. Upstream developers are in no different 
position than complete strangers in this respect. The documentation for 
debian packagers is out there, so I don't understand what you mean by 
educating developers...

FWIW, if you want to provide rudimentary debian/rpm/slackware packages, you 
can use the checkinstall tool.


Saludos,
Felipe Sateler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20090402/47ea18e1/attachment-0001.pgp