[Fwd: Re: [LAD] [LAU] Join the Debian Multimedia Team! (to improve the state of Linux audio)]
fsateler at gmail.com
Thu Apr 2 02:22:59 UTC 2009
El 01/04/09 21:16 Grammostola Rosea escribió:
> 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. ?
> 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
FWIW, if you want to provide rudimentary debian/rpm/slackware packages, you
can use the checkinstall tool.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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
More information about the pkg-multimedia-maintainers