Re: Non-Debian packaging practice
On Sat, Mar 11, 2006 at 07:00:12PM -0000, StealthMonger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Justin Pryzby <justinpryzby@users.sourceforge.net> writes:
>
> > On Fri, Mar 10, 2006 at 10:35:22PM -0000, StealthMonger wrote:
>
> > > Is there a document describing software packaging good practices for
> > > general use, not specific to Debian, preferably in electronic form?
> > I'm not entirely sure I understand what you mean.
>
> Sorry the question was not clear.
>
> > > Debian discourages creating Debian-native packages: "This type of
> > > packaging is only appropriate for the debian-specific packages, which
> > > will never be useful in another distribution." [1] But creating it
> > > for other distributions requires some knowledge of what those other
> > > distributions expect of a package.
> > Of course Debian doesn't attempt to describe with other distros
> > expect. Since you're talking about stuff that will apparently be used
> > in other distros, you want a non native package anyway, right?
>
> Right. That's the point. The Debian "maint-guide" [1] is geared to
> deriving a Debian package from a pre-existing "upstream" package.
> Further, the quote above implies that if one is writing a new package
> from scratch, it's better to write it for general distribution and
> then convert it to a Debian package.
>
> But that requires knowledge of how to write a package for general
> distribution. Hence the question.
>
> Here's an example of the issues that come up. Is it good practice
> outside of Debian for a package to always have a make file, even if
> the package contains no compilable code, only scripts to install? Or
> is a simple install script acceptable?
Some convenient interface for doing whatever has to be done; in the
case of shell scripts, just provide a makefile or shscript, or python
or whatever you prefer which accepts PREFIX or DESTDIR or whatever..
It doesn't matter so much if it is #! /bin/sh or #! /usr/bin/make -f,
especially since they both have "./foo install" interface.
Justin
Reply to: