Ubuntu Wiki

   1 [20:01] <james_w> hello everyone, my name is James Westby, and I'm a developer of pkgme
   2 [20:01] <james_w> later you'll be able to play along, if you want to prepare for that then you can run "sudo apt-get install devscripts debhelper python-virtualenv bzr" and then "bzr branch lp:pkgme"
   3 [20:01] <james_w> that should get you set up with the packages you need and get you a copy of the code
   4 [20:02] <james_w> with that out of the way, let's go back to the beginning
   5 [20:02] <james_w> pkgme is a tool to help you package applications for Ubuntu
   6 [20:03] <james_w> after you've written an application you need to package it up so that you can get it in to a PPA and then in to the software-center
   7 [20:04] <james_w> it may be that you know how to do that already, and if so great, but not everyone knows how to do it already
   8 [20:04] <james_w> if you don't know how to do it then you can learn yourself, find someone that does know, or try and use a tool to do it for you
   9 [20:05] <james_w> in Debian/Ubuntu there are three classes of tool that help you to do this
  10 [20:05] <james_w> the first is like checkinstall, which is nicer than installing software without it, but isn't suited for producing packages to distribute to other people
  11 [20:05] <james_w> the second class is things like dh-make
  12 [20:06] <james_w> this gives you a skeleton to work with, but usually you need to know a lot about packaging to get something useful
  13 [20:06] <james_w> so it's mainly used by Debian/Ubuntu developers who want a skeleton to start from, or by those who are reading packaging guides
  14 [20:06] <james_w> but it doesn't really help that last group
  15 [20:07] <james_w> the third class is specialised tools like dh-make-perl
  16 [20:07] <james_w> these deal with one type of package (in that case perl libraries)
  17 [20:07] <james_w> they do it well, but you have to know that they exist
  18 [20:08] <james_w> and also they all work differently, and every time someone wants to write a new one then they have to start almost from scratch, and implement the same things such as writing out the package files
  19 [20:08] <james_w> so where does pkgme fit in to this?
  20 [20:09] <james_w> pkgme sits somewhere between the second and third class
  21 [20:09] <james_w> it gets the benefits of the third class, in that it produces good packages with little knowledge required on the users part
  22 [20:10] <james_w> but it has the advantage that it has a single user interface, it re-uses code across the different types of packages, and you there's only one place to look to know if your package type is supported
  23 [20:10] <james_w> obviously though, it needs to know how to handle each type of package
  24 [20:11] <james_w> here a type of package is referring to a set of packages that have a convention about how they should be packaged
  25 [20:11] <james_w> this means you have things like "python with a setup.py"
  26 [20:11] <james_w> perl with a Makefile.PL
  27 [20:11] <james_w> java with an ant build.xml
  28 [20:12] <james_w> and it extends further as well, we recently added a backend for pdfs, to support the books and magazines that are being sold in Ubuntu Software Center now
  29 [20:12] <james_w> each of these types of package is supported through a pkgme "backend"
  30 [20:13] <james_w> the core of pkgme takes care of all the intracacies of debian package files etc., and the backend supplies the knowledge of that type of package
  31 [20:13] <james_w> so when you run pkgme it first asks each backend to decide whether it can deal with the type of package in question
  32 [20:13] <james_w> each backend returns a score
  33 [20:13] <james_w> they can return 0 if they don't know what it is
  34 [20:14] <james_w> or they can return 10 if they know how to provide some information
  35 [20:14] <james_w> the reason it is is score is so that you can have more specialised backends
  36 [20:14] <james_w> for instance, a ruby backend may see a ruby package and report "10"
  37 [20:15] <james_w> but then a ruby-on-rails backend could see that it was really a RoR project, not a plain ruby one, and take over by reporting 20 for the score
  38 [20:15] <james_w> this isn't limited to two levels either
  39 [20:15] <james_w> there may be a particular subclass of RoRs projects that could have its own backend
  40 [20:16] <james_w> once the backends have all reported their scores then the one with the highest score is used for the next part
  41 [20:16] <james_w> at this point pkgme starts asking the backend for some information about the project
  42 [20:16] <james_w> "what is the name of the project?"
  43 [20:16] <james_w> "what is the version?"
  44 [20:16] <james_w> "what dependencies does it have?"
  45 [20:16] <james_w> "what's the description?"
  46 [20:16] <james_w> etc.
  47 [20:17] <james_w> once pkgme has all this information it puts it in to its templates and writes out the packaging
  48 [20:17] <james_w> so, let's see how all this fits together
  49 [20:17] <james_w> if you have downloaded the branch of pkgme you will see that it has no ./debian/ directory
  50 [20:18] <james_w> this means that it itself is not packaged
  51 [20:18] <james_w> so let's try using pkgme on itself
  52 [20:18] <james_w> cd in to the pkgme directory that bzr gave you
  53 [20:18] <james_w> and run:
  54 [20:18] <james_w> virtualenv --no-site-packages virtualenv
  55 [20:18] <james_w> source ./virtualenv/bin/activate
  56 [20:18] <james_w> python setup.py develop
  57 [20:18] <james_w> pkgme
  58 [20:19] <james_w> it will think for a few seconds, and then will have written out the debian directory
  59 [20:19] <james_w> it will then try and build the source package
  60 [20:19] <james_w> that may or may not work for you (given that it's supposed to be used by the person that built the app)
  61 [20:19] <james_w> that's it, we didn't have to tell pkgme anything about what we were doing, it just figured everything out, and made some sensible decisions for us
  62 [20:20] <ClassBot> There are 10 minutes remaining in the current session.
  63 [20:20] <james_w> it's likely always going to be possible that an experienced packager will find some better way of packaging the app, but that's ok
  64 [20:20] <james_w> pkgme will produce something workable, which is the immediate goal
  65 [20:21] <james_w> there's one thing I've glossed over so far
  66 [20:21] <james_w> what if pkgme doesn't know how to deal with your particular application?
  67 [20:21] <james_w> there are two possibilities here
  68 [20:21] <james_w> the first is that your app looks like one of the types that pkgme knows about, but differs somehow
  69 [20:21] <james_w> in these cases pkgme will give you an error, or the package won't work
  70 [20:22] <james_w> if it doesn't turn out to be a pkgme bug, then unfortunately it's a sign that you will have to learn something about packaging, or find someone that does
  71 [20:22] <james_w> we will try and accomodate different ways of doing things, but we can't have an automated tool know how to deal with everything
  72 [20:23] <james_w> so when you are writing an app, stick to the conventions of whatever type of project you are writing
  73 [20:23] <james_w> the second case is that pkgme doesn't know how to handle your type of project
  74 [20:23] <james_w> in those cases you would need to write a pkgme backend
  75 [20:23] <james_w> or at least work together with us to write it
  76 [20:24] <james_w> this doesn't need any packaging knowledge (though it doesn't hurt)
  77 [20:24] <james_w> as I said before there are two things the backend needs to be able to do
  78 [20:24] <james_w> the first is decide whether a particular project is something it can handle
  79 [20:24] <james_w> this is usually looking for a particular file (e.g. setup.py) and maybe some other checks
  80 [20:24] <james_w> the second thing is answer some questions about the project
  81 [20:24] <james_w> what the name of it is
  82 [20:25] <james_w> what the dependencies are
  83 [20:25] <ClassBot> There are 5 minutes remaining in the current session.
  84 [20:25] <james_w> all things that don't really need any packaging knowledge
  85 [20:26] <james_w> so if you are in this situation find us on launchpad (https://launchpad.net/~pkgme-developers) or on IRC (#pkgme)
  86 [20:26] <james_w> and we'll help you write a backend (it takes about an hour to write something useful in my experience)
  87 [20:27] <james_w> then you and everyone who writes the same types of apps can benefit from automatic packaging
  88 [20:27] <james_w> any questions?
  89 [20:27] <james_w> in the meantime I'll write a little about what we at Canonical are building based on pkgme
  90 [20:28] <james_w> when you submit a commercial application to https://developer.ubuntu.com/dev then Canonical will help you package it
  91 [20:28] <james_w> in order to speed that process up and allow more applications to be available on Ubuntu we are putting pkgme behind that form so that an attempt will be made to package your app automatically
  92 [20:29] <james_w> for certain types of application at least
  93 [20:29] <james_w> in addition, we're going to be trying to help libre applications too, by working with the ARB to have pkgme help developers and them to package applications
  94 [20:29] <ClassBot> tomalan asked: ​ can pkgme als guess dependencies (e.g. by examining PKG_CHECK_MODULE in configure.ac in autotools)?
  95 [20:30] <james_w> that would be how it did it for autotools, yes