david <[EMAIL PROTECTED]> writes:
> On Sat, 2008-05-31 at 13:06 +0800, jam wrote:
>> On Saturday 31 May 2008 10:00:04 [EMAIL PROTECTED] wrote:
>> > >> It is also helpful to try and avoid building your own custom packages as
>> > >> much as possible. In many cases alternatives exist, or waiting for an
>> > >> upgrade has a longer cost.
>> > >
>> > > <SNIP>
>> > >
>> > >> Yes: checkinstall is a good tool for doing this, although the various
>> > >> 'dh-make-*' packages provide good support for Perl and PHP modules.
[...]
> For example, if I'm going to build a package for Cinepaint ... what's
> the most appropriate approach? I've never built a package.
I would advise that the best path is:
1. Read the distribution packaging guidelines and standards, and
understand them. Without that it is easy to cause nasty problems for
yourself later.
2. Find an existing package of the tool; cinepaint /was/ in Debian and
Ubuntu previously, so the old version will be a good template.
3. Failing that, find a similar package and study it until you
understand why it is put together the way it is.
4. Update the packages you have, or build a new one using distribution
supplied helpers as much as possible. (eg: dh-make)
5. Build your distribution package, install, test.
6. Modify the package to fix issues you found in testing, update the
version of your package to reflect that, and reinstall.
7. If legally permissible, publish your package (at least source,
ideally binary) for others to benefit from.
The best way to achieve 7 is so submit your changes in the distribution
preferred fashion (debdiff, for Ubuntu) to the distribution maintainer,
if there is one -- and if not, perhaps you should volunteer?
Make sure you understand the legal risks you might be taking, especially
licensing related risks, at step 7 though.
> These were my "howto" notes I kept when I built Cinepaint on Feisty:
>
> [EMAIL PROTECTED]:~/howto $ cat cinepaint
> download cinepaint, extract into /usr/local/cinepaint-0.22-0
As a rule of thumb you should put the source into one of two places:
~/src/cinepaint-0.22-0 (preferable)
/usr/src/cinepaint-0.22-0
Using your home dir is strongly preferable because it avoids giving your
uid elevated privileges to the rest of the system, and because it is
reusable experience if you ever need build software on a machine where
you /can't/ get those privileges.
> sudo apt-get install libopenexr-dev
sudo aptitude install ...
Aptitude is generally considered a superior replacement for apt-get
these days, since it implements considerably better conflict resolution
algorithms. Not that apt-get is going to cause (much) grief or
anything.
[...]
> # make install
A better replacement for this is:
sudo aptitude install checkinstall
checkinstall -D make install
That will build a .deb package, which you can then remove using the
standard tools at a later point. It will, as one poster pointed out,
not be a very /good/ package, but it is at least trivial to remove.
Otherwise, look forward to cleaning it up by hand when you want to get
rid of the mess (or reinstalling your machine at some stage, of course.)
Regards,
Daniel
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
