GIO support

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

GIO support

Torsten Schoenfeld
I just pushed a branch called "gio-support" to our repository:
<http://git.gnome.org/browse/perl-Glib/log/?h=gio-support>.  It contains
an initial attempt at GIO bindings via gobject-introspection.  It's
still a bit rough around certain edges, but should otherwise be pretty
complete and functional.  Code review, bug reports, unit tests, example
programs, etc. are welcome.
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GIO support

Kevin Ryde
Torsten Schoenfeld <[hidden email]> writes:
>
> gio-support

gio is a separate libgio is it?  Are the wrappers separate similarly?
(Good since perl already does it, and it's only to help msdos, which I
suspect cygwin does already :-)
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GIO support

Torsten Schoenfeld
On 13.04.2010 02:31, Kevin Ryde wrote:
>> gio-support
> gio is a separate libgio is it?  Are the wrappers separate similarly?

The gobject-introspection glue is in Glib.so and Glib.pm.  But all the
gio-specific stuff is in Glib/IO.pm (there is no .so).

But that's just the current situation on the branch.  I'm not sure what
the best way to distribute this code is.

• Current situation: the introspection stuff and Glib::IO are part of
the Glib distribution.  This has the downside of making Glib depend on
the not-yet-stable gobject-introspection library.

• Create a separate Glib::IO distribution including the introspection
stuff and the gio stuff.  Upside: easy distribution without disturbing
Glib.  Downside: the introspection stuff, which is potentially useful to
create bindings for many other libraries, is hidden inside Glib::IO.

• Create a Glib::Object::Introspection distribution providing the
introspection glue, and a separate Glib::IO distribution depending on
it.  Upside: easy distribution, no disturbance on Glib.  Are there
downsides to this approach?
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GIO support

Torsten Schoenfeld
On 13.04.2010 22:26, Torsten Schoenfeld wrote:
> • Create a Glib::Object::Introspection distribution providing the
> introspection glue, and a separate Glib::IO distribution depending on
> it. Upside: easy distribution, no disturbance on Glib. Are there
> downsides to this approach?

Since separating out the two distributions still seemed to make sense to
me today, I went ahead:

   http://git.gnome.org/browse/perl-Glib-Object-Introspection/
   http://git.gnome.org/browse/perl-Glib-IO/

And since all of this is fairly experimental anyway, I decided to use
Dist::Zilla for Glib::IO.  To install it after you cloned it, use "dzil
install".  (Any eventual tarball uploaded to CPAN will use
ExtUtils::MakeMaker normally.)

I'm going to delete the gio-support branch in perl-Glib in a few days.
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GIO support

Kevin Ryde
Torsten Schoenfeld <[hidden email]> writes:
>
> Since separating out the two distributions still seemed to make sense

Sounds good, in particular if perl already covers gio for most things --
if that was the reason nobody had a go at it before :-).

Best split the xs per the .so libraries so as not to drag in more at
runtime than needed.  And split the sources with the upstream sources so
as not to demand more build things than needed.

Can of course also split even further if it seems like a good idea, if
two halves of the library or sources might be used separately.  If gdk
got much separate use then its wrappers could have been separate from
gtk -- not that it does ...
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GIO support

Emmanuele Bassi
In reply to this post by Torsten Schoenfeld
On Sat, 2010-04-17 at 17:04 +0200, Torsten Schoenfeld wrote:

> On 13.04.2010 22:26, Torsten Schoenfeld wrote:
> > • Create a Glib::Object::Introspection distribution providing the
> > introspection glue, and a separate Glib::IO distribution depending on
> > it. Upside: easy distribution, no disturbance on Glib. Are there
> > downsides to this approach?
>
> Since separating out the two distributions still seemed to make sense to
> me today, I went ahead:
>
>    http://git.gnome.org/browse/perl-Glib-Object-Introspection/
>    http://git.gnome.org/browse/perl-Glib-IO/
>
> And since all of this is fairly experimental anyway, I decided to use
> Dist::Zilla for Glib::IO.  To install it after you cloned it, use "dzil
> install".  (Any eventual tarball uploaded to CPAN will use
> ExtUtils::MakeMaker normally.)

this is *beautiful*.

thanks a lot, Torsten; this looks like the shape of things to come for a
lot of GObject-based Perl bindings. I know I'm going to change Clutter
to match this ASAP.

thanks!

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

packaging help?

Jeremy Volkening
In reply to this post by Torsten Schoenfeld
Hello,

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? 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, 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.

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 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. At the moment, I don't need my packages to conform to
standards for the distro repositories, either. 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?

Thanks in advance for any help you can provide.

Jeremy


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Jeremiah Foster-6

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/.

> 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.

> 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.'

> 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 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.

>
> 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/

Best,

Jeremaih
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Jeremy Volkening
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




_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Chris Debenham
In reply to this post by Jeremy Volkening
I currently package/distribute an application depending on gtk2-perl
Have a look at how I did my packaging at
http://lds.cvs.sourceforge.net/viewvc/lds/lyricue/debian/
It isn't too hard - basically you setup a Makefile that does nothing
for 'make' but just copies the files into the right places when 'make
install' is run.
Then create a binary-indep section in your debian/rules file to build
the actual package.
The packaging at the link above will probably be enough to show you
how to get it working.

On 19 April 2010 05:19, Jeremy Volkening <[hidden email]> wrote:

> Hello,
>
> 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? 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, 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.
>
> 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 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. At the moment, I don't need my packages to conform to
> standards for the distro repositories, either. 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?
>
> Thanks in advance for any help you can provide.
>
> Jeremy
>
>
> _______________________________________________
> gtk-perl-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list
>
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Grant McLean
In reply to this post by Jeremy Volkening
On Sun, 2010-04-18 at 15:19 -0400, Jeremy Volkening wrote:
> Hello,
>
> 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?

The easiest way I have found is to organise your source files in the
standard layout used by CPAN distributions.  You might look at using
Module::Starter to get a skeleton layout.

Once you've done that, you can use the dh-make-perl tool (available via
apt-get) to create a .deb from the top-level directory of your source,
e.g.:

  dh-make-perl --build .

For an example, see this project (a GTK app for bulk-copying USB keys):

  http://github.com/grantm/usb-key-copy-con

Scroll down that page for a screenshot and project overview.

In this example, almost all my code lives in .pm files in the 'App::*'
namespace under the lib directory, e.g.:

  lib/App/USBKeyCopyCon.pm

The app uses some custom icons that live in a .pm file:

  lib/App/USBKeyCopyCon/Chrome.pm

There's also a .wav file that lives in the same directory - that's
probably not strictly kosher but it works :-)

The script which is used to launch the app is a simple wrapper that
lives in the bin directory.

When dh-make-perl turns it all into a .deb, the .pm files get installed
under /usr/lib and the wrapper script ends up in /usr/bin.

If your app depends on other packages, you would edit the debian/control
file (which was generated by dh-make-perl) to list the dependencies and
then rebuild the .deb with:

  dpkg-buildpackage -rfakeroot

> 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.

Are these libraries part of your app?  If so, just put them in the lib
directory of your source tree and everything should be fine.  If not,
then they should be packaged separately.  It certainly wouldn't be
kosher for files in a .deb to depend on files living under /usr/local.

Cheers
Grant


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Jeremy Volkening
Thanks to everyone for your replies. Your projects are similar in
complexity to what I'm doing and I'll study your source to get a better
idea of what you have done. Chris's suggestion was closer to the
direction I had been heading. However, I think I may have dismissed
dh-make-perl somewhat prematurely.

I was assuming that packages set up using dh-make-perl would be
installed in the same place most modules are installed when using the
CPAN one-liner (/usr/share/perl5/... on my system), and this didn't seem
appropriate for a standalone app. According to what Grant says, I guess
I had the wrong impression.

Is it safe to say that I was wrong to differentiate between packaging a
standalone app and a reusable module? From what I've been hearing, it
sounds like dh-make-perl is still the way to go.

Jeremy

On Mon, 2010-04-19 at 12:00 +1200, Grant McLean wrote:

> On Sun, 2010-04-18 at 15:19 -0400, Jeremy Volkening wrote:
> > Hello,
> >
> > 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?
>
> The easiest way I have found is to organise your source files in the
> standard layout used by CPAN distributions.  You might look at using
> Module::Starter to get a skeleton layout.
>
> Once you've done that, you can use the dh-make-perl tool (available via
> apt-get) to create a .deb from the top-level directory of your source,
> e.g.:
>
>   dh-make-perl --build .
>
> For an example, see this project (a GTK app for bulk-copying USB keys):
>
>   http://github.com/grantm/usb-key-copy-con
>
> Scroll down that page for a screenshot and project overview.
>
> In this example, almost all my code lives in .pm files in the 'App::*'
> namespace under the lib directory, e.g.:
>
>   lib/App/USBKeyCopyCon.pm
>
> The app uses some custom icons that live in a .pm file:
>
>   lib/App/USBKeyCopyCon/Chrome.pm
>
> There's also a .wav file that lives in the same directory - that's
> probably not strictly kosher but it works :-)
>
> The script which is used to launch the app is a simple wrapper that
> lives in the bin directory.
>
> When dh-make-perl turns it all into a .deb, the .pm files get installed
> under /usr/lib and the wrapper script ends up in /usr/bin.
>
> If your app depends on other packages, you would edit the debian/control
> file (which was generated by dh-make-perl) to list the dependencies and
> then rebuild the .deb with:
>
>   dpkg-buildpackage -rfakeroot
>
> > 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.
>
> Are these libraries part of your app?  If so, just put them in the lib
> directory of your source tree and everything should be fine.  If not,
> then they should be packaged separately.  It certainly wouldn't be
> kosher for files in a .deb to depend on files living under /usr/local.
>
> Cheers
> Grant
>
>
> _______________________________________________
> gtk-perl-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list



_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Grant McLean
On Sun, 2010-04-18 at 22:00 -0400, Jeremy Volkening wrote:
> Is it safe to say that I was wrong to differentiate between packaging a
> standalone app and a reusable module?

>From the Debian standpoint, applications and modules/libraries are
packaged in the same way.

>From the CPAN perspective, it was originally envisaged that modules
would be packaged in a different way to scripts.  However the tools that
grew up around the package format for modules meant that it became the
'winner' and is now used for scripts too.  It turns out that it's easier
to write tests for modules than for scripts so building your application
as a simple wrapper around one or more modules is preferred by many.

Cheers
Grant

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Mario Kemper
In reply to this post by Jeremy Volkening
If you want to build a very simple .deb package you can also build it
with dpkg -b.

I've created a very simple example here:
http://dl.dropbox.com/u/961086/myapp-1.0.tar

The only additional file you need in this case is debian/control.

When you extract the above tarball you'll get a directory hierachy like
that:
myapp-1.0
--> usr/
      --> bin/
            --> myscript
--> debian/
       --> control

All you have to do to get the debian package is:

1) go to the folder where you have extracted the tarball
2) enter dpkg -b myapp-1.0


Please note: This is not the "official" debian way and it is not good
practice, but packaging is not a very trivial task. In order to get
"best practice" debian packages please use the CPAN structure as the
canonical source and use dh-make-perl to build the package (as already
mentioned in earlier posts).

Regards
Mario
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Kevin Ryde
In reply to this post by Jeremy Volkening
Jeremy Volkening <[hidden email]> writes:
>
> b) downloading source packages of gtk2-perl based apps

For what it's worth I've been using cdbs with a debian dir left in the
cpan .tar.gz (eg. Gtk2::Ex::Clock for a simple example), which means
"fakeroot debian/rules binary" builds from the tar.  (Latest cdbs
introduces a pointless renaming of the perl .mk files designed to be
incompatible with older debian, but that can be ignored.)

dh-make-perl can be persuaded to give reasonable output but you probably
want to massage the description fields and probably the dependencies
list too.  (It also like to generate debhelper 7 format to limit
backward compatibility.)

I tried cpan2deb but it seemed to end up with slightly different layout
than native debian packages.  Perhaps that's changed by now.
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Chris Debenham
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think there is a little confusion on what the original poster was
asking  - answers are coming to two separate questions.
When it comes to packaging perl things there are two separate areas.
There is the packaging of perl modules (like Gtk2::Ex::Clock) and
there is the entirely separate area for packaging applications that
happen to be written in perl.
For packaging perl modules there are the various cpan2deb tools along
with special perl module stuff built into dh_make.
For packaging applications which are written in perl you don't need
any other that stuff.  You package it the same as any other
application but with the end result coming from a binary-indep rule
rather than a binary-arch rule (so "Architecture: all" is in the
control file rather than a specific arch)

So I guess the question is to the original poster - are you packaging
a perl module itself (to be used by other things) or are you packaging
an application which uses perl?
Depending on which is relevant the answer is different


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)

iEYEARECAAYFAkvM38cACgkQenvI4bc00fWOgQCeMs7SXzYMwpnor8a/44Mpxalh
HFsAn0RooZxYg3QQ4Tyx5zOks0smrf+r
=4evS
-----END PGP SIGNATURE-----

On 20 April 2010 08:25, Kevin Ryde <[hidden email]> wrote:

> Jeremy Volkening <[hidden email]> writes:
>>
>> b) downloading source packages of gtk2-perl based apps
>
> For what it's worth I've been using cdbs with a debian dir left in the
> cpan .tar.gz (eg. Gtk2::Ex::Clock for a simple example), which means
> "fakeroot debian/rules binary" builds from the tar.  (Latest cdbs
> introduces a pointless renaming of the perl .mk files designed to be
> incompatible with older debian, but that can be ignored.)
>
> dh-make-perl can be persuaded to give reasonable output but you probably
> want to massage the description fields and probably the dependencies
> list too.  (It also like to generate debhelper 7 format to limit
> backward compatibility.)
>
> I tried cpan2deb but it seemed to end up with slightly different layout
> than native debian packages.  Perhaps that's changed by now.
> _______________________________________________
> gtk-perl-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list
>
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Kevin Ryde
Chris Debenham <[hidden email]> writes:
>
> packaging applications that happen to be written in perl.

Though of course a Makefile.PL can still be used for a standalone perl
script.  I do one of my little scripts like that (not on cpan as yet).
Handy to express module dependencies.

(A mixed script with some private modules is probably closer to module
packaging, as mentioned by others.)
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Jeremy Volkening
In reply to this post by Chris Debenham
On Tue, 2010-04-20 at 08:57 +1000, Chris Debenham wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think there is a little confusion on what the original poster was
> asking  - answers are coming to two separate questions.
> When it comes to packaging perl things there are two separate areas.
> There is the packaging of perl modules (like Gtk2::Ex::Clock) and
> there is the entirely separate area for packaging applications that
> happen to be written in perl.
> For packaging perl modules there are the various cpan2deb tools along
> with special perl module stuff built into dh_make.
> For packaging applications which are written in perl you don't need
> any other that stuff.  You package it the same as any other
> application but with the end result coming from a binary-indep rule
> rather than a binary-arch rule (so "Architecture: all" is in the
> control file rather than a specific arch)
>
> So I guess the question is to the original poster - are you packaging
> a perl module itself (to be used by other things) or are you packaging
> an application which uses perl?
> Depending on which is relevant the answer is different

That is exactly the dilemna I was running up against when I first
started out, and I suppose what I was trying to get at in my initial
post. Most of the docs seem to be geared toward packaging modules, while
I'm interested in packaging full-fledged apps. A lot of my code <is>
broken up into modules, but I also need to install .desktop files, mime
types, application/mimetype icon themes, data files, user config files,
etc. It seemed like Module::Build might have the flexibility to do all
of this, but it doesn't look like it's compatible with dh-make-perl.

I guess I was hoping someone might say, "Hey, what you want is this
book/howto/tutorial called "Packaging Perl Applications for the GNOME
Desktop" or something equally to the point. I've since decided that I'm
just being lazy, and that I really need to get into the nitty gritty of
Makefiles and the GNOME specifications to do what I want to do in the
"right" way. Thanks to everyone for the advice.

Jeremy

>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)
>
> iEYEARECAAYFAkvM38cACgkQenvI4bc00fWOgQCeMs7SXzYMwpnor8a/44Mpxalh
> HFsAn0RooZxYg3QQ4Tyx5zOks0smrf+r
> =4evS
> -----END PGP SIGNATURE-----
>
> On 20 April 2010 08:25, Kevin Ryde <[hidden email]> wrote:
> > Jeremy Volkening <[hidden email]> writes:
> >>
> >> b) downloading source packages of gtk2-perl based apps
> >
> > For what it's worth I've been using cdbs with a debian dir left in the
> > cpan .tar.gz (eg. Gtk2::Ex::Clock for a simple example), which means
> > "fakeroot debian/rules binary" builds from the tar.  (Latest cdbs
> > introduces a pointless renaming of the perl .mk files designed to be
> > incompatible with older debian, but that can be ignored.)
> >
> > dh-make-perl can be persuaded to give reasonable output but you probably
> > want to massage the description fields and probably the dependencies
> > list too.  (It also like to generate debhelper 7 format to limit
> > backward compatibility.)
> >
> > I tried cpan2deb but it seemed to end up with slightly different layout
> > than native debian packages.  Perhaps that's changed by now.
> > _______________________________________________
> > gtk-perl-list mailing list
> > [hidden email]
> > http://mail.gnome.org/mailman/listinfo/gtk-perl-list
> >


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Brian Manning
On Tue, May 4, 2010 at 3:58 PM, Jeremy DS Volkening
<[hidden email]> wrote:
> I guess I was hoping someone might say, "Hey, what you want is this
> book/howto/tutorial called "Packaging Perl Applications for the GNOME
> Desktop" or something equally to the point. I've since decided that I'm
> just being lazy, and that I really need to get into the nitty gritty of
> Makefiles and the GNOME specifications to do what I want to do in the
> "right" way. Thanks to everyone for the advice.

"Hey, what you may want to do is find an existing Gtk2-Perl app Debian
package and use it as an example for your package's layout".

apt-cache rdepends libgtk2-perl gave me a nice list of packages that
depend on libgtk2-perl. I can give you a few suggestions from that
list:

tinyca
greenwich
podbrowser

Thanks,

Brian
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: packaging help?

Jeremy Volkening
On Tue, 2010-05-04 at 17:25 -0700, Brian Manning wrote:

> On Tue, May 4, 2010 at 3:58 PM, Jeremy DS Volkening
> <[hidden email]> wrote:
> > I guess I was hoping someone might say, "Hey, what you want is this
> > book/howto/tutorial called "Packaging Perl Applications for the GNOME
> > Desktop" or something equally to the point. I've since decided that I'm
> > just being lazy, and that I really need to get into the nitty gritty of
> > Makefiles and the GNOME specifications to do what I want to do in the
> > "right" way. Thanks to everyone for the advice.
>
> "Hey, what you may want to do is find an existing Gtk2-Perl app Debian
> package and use it as an example for your package's layout".
>
> apt-cache rdepends libgtk2-perl gave me a nice list of packages that
> depend on libgtk2-perl. I can give you a few suggestions from that
> list:
>
> tinyca
> greenwich
> podbrowser
>
> Thanks,
>
> Brian

Thanks - I've already done this with about half a dozen apps (including
podbrowser) I found through web searches and other responses, but that
command is certainly a good way to find more. Although everyone seems to
go about it a bit differently, seeing what others have done has
definitely helped out.

Jeremy


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list