1838
Comment:
|
← Revision 23 as of 2009-03-16 03:33:14 ⇥
5997
converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
== evolution-data-server == * Most build-deps figured by inspection of ./configure.in and 'find /e-d-s/source -name "*.c" -or -name "*.h" -exec grep "\#include" {} \;' * One "transient dependency" assumption is made in build-deps - it is assumed that libgnomeui-dev pulls in libxml2-dev, libglib2.0-dev, libgtk2.0-dev, libglade2-dev, liborbit2-dev, libbonobo2-dev * -dev deps are set to match the pkgconfig .pc files. If they are wrong, notify upstream |
== Build-deps: == * Build deps should include all modules or packages as required in configure.in * 'find /e-d-s/source -name "*.c" -or -name "*.h" -exec grep "\#include" {} \;' can discover things configure.in should have checked for or could have skipped checking. These things should be reported upstream == -dev packages Depends: == * To find dependencies on other libraries, assume that the pkg-config files in /usr/lib/pkgconfig are correct, and match the dependencies in "Requires:" there. If that is not enough, notify upstream and fix |
Line 9: | Line 11: |
* Most build-deps figured by inspection of ./configure.in and 'find /evo/source -name "*.c" -or -name "*.h" -exec grep "\#include" {} \;' * One "transient dependency" assumption is made - it is assumed that libgnomeui-dev pulls in libglib2.0-dev, libgtk2.0-dev, libglade2-dev, libgnomecanvas2-dev, liborbit2-dev, libbonobo2-dev, libgconf2-dev, libgnomevfs2-dev, libbonoboui2-dev * -dev deps are set to match the pkgconfig .pc files. If they are wrong, notify upstream * Build-depends on gtkhtml3.8 because it needs /usr/share/gtkhtml-3.8/Editor.idl * Build-depends on e-d-s-dev for convenience, assuming that e-d-s-dev pull in all -devs. Could have made more finely grained dependencies * Are all of "libdbus-glib-1-dev, libdbus-1-dev, libnm-glib-dev" build-deps necessary? |
* Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], cdbs (>= 0.4.37) [-dbg support], dpkg-dev (>= 1.13.19) [binary:Source], pkg-config (not mentioned in configure.in but certainly used), scrollkeeper (not mentioned in configure.in but used), gtkhtml3.8 (needs /usr/share/gtkhtml-3.8/Editor.idl), libdbus-1-dev (needed to check API version before it has stabilised), libcamel1.2-dev has version requirement although not in configure.in (also in evolution-dev), gnome-doc-utils (GNOME_DOC_INIT) * Build-deps not included: gettext (required by intltool) == evolution-data-server == * Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], cdbs (>= 0.4.37) [-dbg support], dpkg-dev (>= 1.13.19) [binary:Source], pkg-config (not mentioned in configure.in but certainly used), libdb4.4-dev | libdb-dev (instead of internal libdb, both work) * Build-deps not included: gettext (required by intltool) * Unkown reason: * Add libedataserver1.2-dev Depends: libnspr4-dev * Add libcamel1.2-10 Depends: libnss3 | libnss3-0d * Add libebook1.2-9 Depends: libnspr4 | libnspr4-0d * Add libedataserverui1.2-8 Depends: libnspr4 | libnspr4-0d |
Line 17: | Line 24: |
* Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], cdbs (>= 0.4.37) [-dbg support], dpkg-dev (>= 1.13.19) [binary:Source], pkg-config (not mentioned in configure.in but certainly used) * Build-deps not included: gettext (required by intltool), libsoup2.2-dev (only needed for testgtkhtml) |
|
Line 20: | Line 29: |
* configure.in should probably check for libbonobo-2.0 instead of libbonobo-2.0 * configure.in: GTKHTML_MODULES should probably contain only glib, gtk, gconf and libgnomeprint |
* configure.in should probably check for libbonobo-2.0 instead of libbonoboui-2.0 * configure.in should probably check for atk, glib-2.0, libgnomecanvas-2.0 * configure.in: GTKHTML_MODULES should probably contain only glib, atk, gtk, gconf, and libgnomeprint |
Line 23: | Line 33: |
* libgtkhtml-3.8.pc: should probably require gtk, libgnomeprint, glib, gdk, and gconf == evolution-exchange == * Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], pkg-config (not mentioned in configure.in but certainly used) * Build-deps not included: gettext (required by intltool) == binNMU support == {{{ <lool> feedback: so on that bin NMU thing, it's a new feature the release team gained recently <lool> feedback: the concept is to download the source from the archive, and re build the binary packages <lool> _feedback: it's vert special in that the source doesn't change, so Source-Version is still the same version <_feedback> lool: ok, and that's it, so everything should depend on Source-Version <lool> _feedback: when we write strict dependencies, we used to write "={Source-Version}' (or >=) <lool> but that breaks with bin NMUs <_feedback> hum.. so? <lool> _feedback: if the source has eg 2.1.0-1, the bin NMU will have 2.1.0-1+b1 for a version <lool> yet the =source-version dep will look like = 2.1.0-1 <lool> but this won't exist in the archive anymore <lool> _feedback: so the solution is to introduce a new substvar, binary:Version <_feedback> ok, so, depending on ={binary:Version} solves it? <lool> making a package bin NMU ready means fixing the dependency between arch: any packages to use $binary:Version <lool> but you need a build-dep on a newer dpkg-dev for this <lool> you also have to be careful with arch: all packages which won't be bin NMU ed <lool> you should always depend on them with =source:Version (same as Source-Version, but looks like binary:Version) <lool> and they should depend on arch: any packages with >= source:Version <lool> _feedback: so that's it :) }}} == *.private in pkg-config files == {{{ <shaka> lool: for some reason i got the "housekeeping task" spirit over me just in time for this upload. what i did was match -dev depends with .pc Requires: -- is that the right way to do it? <vorlon> shaka: if there are no .la files, then yes <vorlon> shaka: Requires: and Requires.private: if you want to support private linking out of the box; considerably more if you have .la files that embed references to all kinds of crap <lool> shaka: yes, that's correct <lool> shaka: you need to depend on packages shipping headers or libraries or pc files referenced from your pc files <lool> shaka: a nice thing to do is to move headers/modules/libs which are only useful to link statically from requires to requires.private, or from libs to libs.private <lool> (in pc files) <lool> shaka: however, moving requires to requires.privates when this pulled headers (-I flags) might break stuff, there's a bug against pkg-config for that <lool> shaka, heikkih: hmm e-d-s isn't doing terribly good :-/ <shaka> lool: so, what if your foo-dev has foo.pc and /usr/include/foo/foo.h with a #include <bar.h> and there is no Requires: bar-pkg <shaka> lool: is that a reason to add it to Requires: (that would be notify upstream)? <lool> shaka: you can also add -I to cflags <shaka> lool: yes, of course <lool> shaka: one part of the pkg-config discussion in the bug is whether such inclusion of headers (API) should cause a link to the included library }}} |
Packaging notes
Build-deps:
- Build deps should include all modules or packages as required in configure.in
- 'find /e-d-s/source -name "*.c" -or -name "*.h" -exec grep "\#include" {} \;' can discover things configure.in should have checked for or could have skipped checking. These things should be reported upstream
-dev packages Depends:
- To find dependencies on other libraries, assume that the pkg-config files in /usr/lib/pkgconfig are correct, and match the dependencies in "Requires:" there. If that is not enough, notify upstream and fix
evolution
Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], cdbs (>= 0.4.37) [-dbg support], dpkg-dev (>= 1.13.19) [binary:Source], pkg-config (not mentioned in configure.in but certainly used), scrollkeeper (not mentioned in configure.in but used), gtkhtml3.8 (needs /usr/share/gtkhtml-3.8/Editor.idl), libdbus-1-dev (needed to check API version before it has stabilised), libcamel1.2-dev has version requirement although not in configure.in (also in evolution-dev), gnome-doc-utils (GNOME_DOC_INIT)
- Build-deps not included: gettext (required by intltool)
evolution-data-server
Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], cdbs (>= 0.4.37) [-dbg support], dpkg-dev (>= 1.13.19) [binary:Source], pkg-config (not mentioned in configure.in but certainly used), libdb4.4-dev | libdb-dev (instead of internal libdb, both work)
- Build-deps not included: gettext (required by intltool)
- Unkown reason:
- Add libedataserver1.2-dev Depends: libnspr4-dev
- Add libcamel1.2-10 Depends: libnss3 | libnss3-0d
- Add libebook1.2-9 Depends: libnspr4 | libnspr4-0d
- Add libedataserverui1.2-8 Depends: libnspr4 | libnspr4-0d
gtkhtml3.8
Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], cdbs (>= 0.4.37) [-dbg support], dpkg-dev (>= 1.13.19) [binary:Source], pkg-config (not mentioned in configure.in but certainly used)
- Build-deps not included: gettext (required by intltool), libsoup2.2-dev (only needed for testgtkhtml)
- Should /usr/share/gtkhtml-3.8/Editor.idl be installed to /usr/share/idl?
- configure.in probably does not need to check for libglade-2, since it is not used
- configure.in should probably check for libgnomeprint-2.2 instead of libgnomeprintui-2.2
- configure.in should probably check for libbonobo-2.0 instead of libbonoboui-2.0
- configure.in should probably check for atk, glib-2.0, libgnomecanvas-2.0
- configure.in: GTKHTML_MODULES should probably contain only glib, atk, gtk, gconf, and libgnomeprint
- configure.in: remove build-dep libgnomeprintui-2.2 if GTKHTML is corrected in configure.in
- libgtkhtml-3.8.pc: should probably require gtk, libgnomeprint, glib, gdk, and gconf
evolution-exchange
Build-deps with special explanation: debhelper (>= 5.0.0) [compat 5], pkg-config (not mentioned in configure.in but certainly used)
- Build-deps not included: gettext (required by intltool)
binNMU support
<lool> feedback: so on that bin NMU thing, it's a new feature the release team gained recently <lool> feedback: the concept is to download the source from the archive, and re build the binary packages <lool> _feedback: it's vert special in that the source doesn't change, so Source-Version is still the same version <_feedback> lool: ok, and that's it, so everything should depend on Source-Version <lool> _feedback: when we write strict dependencies, we used to write "={Source-Version}' (or >=) <lool> but that breaks with bin NMUs <_feedback> hum.. so? <lool> _feedback: if the source has eg 2.1.0-1, the bin NMU will have 2.1.0-1+b1 for a version <lool> yet the =source-version dep will look like = 2.1.0-1 <lool> but this won't exist in the archive anymore <lool> _feedback: so the solution is to introduce a new substvar, binary:Version <_feedback> ok, so, depending on ={binary:Version} solves it? <lool> making a package bin NMU ready means fixing the dependency between arch: any packages to use $binary:Version <lool> but you need a build-dep on a newer dpkg-dev for this <lool> you also have to be careful with arch: all packages which won't be bin NMU ed <lool> you should always depend on them with =source:Version (same as Source-Version, but looks like binary:Version) <lool> and they should depend on arch: any packages with >= source:Version <lool> _feedback: so that's it :)
*.private in pkg-config files
<shaka> lool: for some reason i got the "housekeeping task" spirit over me just in time for this upload. what i did was match -dev depends with .pc Requires: -- is that the right way to do it? <vorlon> shaka: if there are no .la files, then yes <vorlon> shaka: Requires: and Requires.private: if you want to support private linking out of the box; considerably more if you have .la files that embed references to all kinds of crap <lool> shaka: yes, that's correct <lool> shaka: you need to depend on packages shipping headers or libraries or pc files referenced from your pc files <lool> shaka: a nice thing to do is to move headers/modules/libs which are only useful to link statically from requires to requires.private, or from libs to libs.private <lool> (in pc files) <lool> shaka: however, moving requires to requires.privates when this pulled headers (-I flags) might break stuff, there's a bug against pkg-config for that <lool> shaka, heikkih: hmm e-d-s isn't doing terribly good :-/ <shaka> lool: so, what if your foo-dev has foo.pc and /usr/include/foo/foo.h with a #include <bar.h> and there is no Requires: bar-pkg <shaka> lool: is that a reason to add it to Requires: (that would be notify upstream)? <lool> shaka: you can also add -I to cflags <shaka> lool: yes, of course <lool> shaka: one part of the pkg-config discussion in the bug is whether such inclusion of headers (API) should cause a link to the included library