Re: [anjuta-devel] [Fwd: Packaging and deployment using GNOME tools]



Hello Johannes, All,
                 في ث، 21-12-2010 عند 00:34 +0100 ، كتب Johannes Schmid:
It would definitly require some assumptions. I will give some examples:
* project uses autotools
* project doesn't require any non-pkg-config libraries
* project is an application (e.g. no library, no multiple packages, no
-doc package)

I guess we can mostly make these assumptions. We could try to deal with
doc packages later.
With these assumptions, it shouldn't be difficult.


Can anyone outline broadly what would be needed to get something like
this working? For example, people at the hackfest mentioned a need to
convert between different package naming standards in distros (for
dependencies etc.). Then would you need some sort of parser (or settings
dialog) that handles deps? And maybe package templates, or packaging
format description files?

OK, I can try to outline a but a of a vision here about how things could
work:

* The user would be presented a dialog where he can set certain "soft"
options on the project:
 - Project description
 - Project version
 - <more metadata>
From my experiment (see below), this would be (for debian) "section",
"priority" (in a combo box to choose one, priority can maybe default to
extra) and (one line and long) description. In addition, the changelog
needs to contain a message and version. There could be a couple more
things for rpm, but not much.

* Anjuta would than try to generate files need for packages:
 - Check with packages provide the .pc files of the libraries we need
(can be done directly with pkg-config names with rpm/yum, some magic is
needed on Ubuntu, would be nice if we had a working PackageKit there).
Debian has a utility (not installed by default) named apt-file that can
find which package has a given file. So it shouldn't be too difficult.

 - More difficult is to find the runtime dependencies since anjuta does
only care about building usually. I don't know a reliable way to come
from -dev package to the normal package.
I can't speak for rpm, but in Debian debhelper takes care of this. Only
needed are dependencies that are not libraries (but maybe this is
excluded by your "is an application" assumption?).


 - Combine metadata and packages into the appropriate files (spec file,
debian/)

For the spec-file I kind of think it can be done and will have a look
into it when I have some spare time. For deb the problem is that dpkg is
usually used to generate a lot of files in the debian directory while we
probably only care about the changelog and the control file. Those are
difficult to handle though because dpkg is very piky on the format and
it is not really machine readable. But maybe people that have more
experience with debian packaging could help out here.
I wouldn't call myself a experienced, but I tried packaging a simple
project generated by the project wizard (gtk application IIRC).

All the files I needed were debian/control debian/compat debian/rules
and debian/changelog : compat contains only a number : 7 (there also
should be a debian/source/format but dpkg doesn't complain if it's
missing for now), rules is a makefile and should be a standard 3-lines
file under your assumptions (it's possible to override things that don't
work, but since we are assuming autotools, there shouldn't be a
problem), changelog and control will contain all the information
gathered from the user. The changelog is pretty standard, and here is
what I used for the control file (> are for quoting and not in the
file):

Source: gtk-foobar
Section: misc
Priority: extra
Maintainer: Abderrahim Kitouni <akitouni src gnome org>
Build-Depends: debhelper (>= 7), libgtk3.0-dev (>= 2.90.3)

Package: gtk-foobar
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Test Gtk Application
 This is my attempt at packaging a trivial gtk application
 using trivial packaging.

In addition, the python-debian package provides python modules for
parsing/writing those if needed [1].

Another question is whether we should make a "native" package (meaning
that the debian directory is in the tarball) or not (debian is in a
separate tarball). I think this isn't much of a problem, we'll see at
some point.

In the same vein are things like : where we should we store these

HTH,
Abderrahim

[1] Writing the plugin in python would be a good excuse to fix the gir
annotations and make sure the API is bindable.




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