Re: packaging help?



Thanks for the quick reply!


On Sun, 2010-04-18 at 22:06 +0200, Jeremiah Foster wrote:
On Apr 18, 2010, at 21:19, Jeremy Volkening wrote:

Hello,

Hi Jeremy,

I'm wondering if anyone can point me toward a good source of
documentation on packaging applications (build on gtk2-perl) for
Debian-based distros?

Well, the canonical source is the
http://www.debian.org/doc/maint-guide/.

Yes, I've worked through this several times. I can't help but feel,
however, that the complexity of what's here is beyond the needs of my
projects. I could be wrong through - I will keep working on it.


I keep banging my head against this step of my
application development with no real progress. So far I've followed
two
routes in trying to figure this out: a) Reading through as many
tutorials as I can find online about .deb packaging,

Here's one more:
http://jeremiahfoster.com/debian/debs-from-cpan.html Since I wrote it
feel free to ask any questions you may have.

I've read about dh-make-perl as one of the (infinite?) ways to go about
packaging. It seems to be based on starting with an existing CPAN
package, however, and it doesn't seem logical for me to package my apps
for CPAN. They are intended to be standalone programs, not modules for
others to build upon. Again, feel free to correct me if my reasoning is
off.


and b) downloading
source packages of gtk2-perl based apps with "apt-get source
<package>"
and examining what others have done. In both cases, I'm a bit
overwhelmed by the fact that everyone seems to go about it
differently.

Well, you're smart to read source I think. There is a generally
accepted way to build packages, or at least one that is widely used in
the debian-perl group. That method, roughly, is using dh-make-perl to
create packages from modules found on CPAN and then following perl
policy as far as your app is concerned.
http://www.debian.org/doc/packaging-manuals/perl-policy/


Most online tutorials seem to deal with preparing packages from
source,
and while my application and supporting libraries are technically, I
suppose, source code (perl), they don't require compilation or any
other
pre-processing steps.

I think you'll find the need to be compiled on different
architectures. Plus packages themselves are binaries - so they need to
be 'compiled.'

Could you explain this further? My code is all pure perl, and I've
intentionally tried to avoid platform-specific dependencies. I've only
tested it on Linux and Win32 platforms, but once all the Gtk+/Glib/etc
libraries and perl bindings are installed, I run the exact same code on
both platforms with no problems. Also, my understanding was that .deb
packages were simply compressed tarballs with a specific directory and
file setup.


I simply need to copy them to the correct
directories, install dependencies (all of which are already
available in
the Debian/Ubuntu repositories), and create application menu entries
and
MIME associations.

This should be relatively straight forward.

At the moment, I don't need my packages to conform to
standards for the distro repositories, either.

Well, if you want to get your software into the distro, they'll want
you to comply with their standards. :)

I know, and perhaps I should just do things the standards-compliant way
from the start, but I don't have any immediate plans to get my software
into their repositories.


I simply want to be able
to provide users with a .deb archive from a sourceforge page to
simplify
their installation (upload to repositories may come later). I've
actually found it easier so far to put together the installer for
the
win32 version than the linux version in which the software is
developed.

On a related note, I will need to figure out the correct way for my
main
app script to find the extra libraries once they are installed. I
currently have the paths hard-coded into the script like this:

use lib '../libs/'; # extra libs
require BioGTK::RE::Digest;
require BioGTK::RE::Collection;
require BioGTK::RE::Manager;
require BioGTK::App::Prefs;

I suppose I could just change the first line to:

use lib '/usr/local/lib/<app-name>/'

and install the library files to that directory, but is there a
better
way to go about this?

Absolutely. You'll have no way of knowing if your users has local::lib
installed. Plus, this problem has already be solved. If you create a
package, you can call in your dependencies and place your package in a
place where it will be able to find the libraries you rely on with a
simply 'use' declaration. This is much simpler for your users as well as
yourself since you don't need to package your dependencies too - they
are likely already packaged, and the OS already knows where all its perl
libraries are so that solves a lot of your problems.


I may not have been clear in this question. The 'libraries' I was
referring to are my own code that is part of my application, not
previously published or separately packaged modules. A lot of it is
fairly app-specific code that I have factored out for ease of
development, and I don't think (at this point) that it would benefit
others as a standalone module or package. I simply need to be sure that
my main script can find the *.pm files where they are eventually
installed - which will presumably be in subdirectories
of /usr/local/lib/<app-name>.


Thanks in advance for any help you can provide.

Read the links I've provided, at least the official debian ones, and
send email to debian-perl should you run into problems - there is
usually someone on that list that can help or point you in the right
direction when packaging perl modules for debian. :)  In general, if you
target Debian as your platform for building your package, it will
install on Debian derivatives as well. More here:
http://pkg-perl.alioth.debian.org/


I'll continue to look into them and the others I have found. I'll direct
further questions to the debian-perl list if that would be more
appropriate. I've just found that most of the debian/perl packaging info
seems to be specific to packaging CPAN modules, and I thought that users
on the gtk2-perl list might have more experience with standalone apps.

Thanks again for the help!

Best,

Jeremaih







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]