[Pkg-phototools-devel] [RFC] Packaging notes for hugin

[Cyril Brulebois]

On 27/01/2008, Bruno Postle wrote:
> 0.7.0 is near release and this is what I've recently added to
> devel/F9.  There is now some point splitting hugin as there is a clear
> division between CLI and GUI parts, with a CLI batch stitching process
> that can run on a headless machine.

OK, moving “hugin, hugin_stitch_project, nona_gui” out of the way means
that one loses the following Depends: in the resulting binary package:
 - libwxbase2.6-0: doesn't pull anything heavy.
   libwxgtk2.6-0 pulls: esd, fontconfig, glib, gtk2, pango, xcomposite,
                        xcursor, and many other x* stuff.

I'm not decided yet, but being able not to install all these packages
when not needed would be nice. And since there are no need to walk
through NEW (Debianish stuff, don't bother, Bruno) again, that'd be
painless to achieve.

Answering to Sebastian, I guess I'll stick to:
  hugin: contains the 3 GUI stuff, depends strictly on hugin-tools.
  hugin-tools: contains the CLI stuff.

-tools sounds better for the CLI stuff, I don't know what one would
expect in a -bin package in the GUI vs CLI case. :)

About -data, we have “Installed-Size: 3440”, so keeping a separate -data
makes sense (answering to Bernd).

This way, we're getting rid of an unneeded package, and getting rid of
(workarounded) circular dependency at the very same time.

From a user point of view, one has likely installed the previous “hugin
metapackage”, so the GUI will still be available by default, so no
troubles when upgrading.

> I've also make hugin-base depend on perl(Image::ExifTool), make and
> enblend, as this batch stitching process requires these.

Thanks. We already had a Suggests: on enblend, and it is currently being
reviewed (and possibly accepted), so I'll bump this to a Recommends:
(stronger dependency) or even to a Depends: (absolute dependency). Since
you're saying “require”, that'll probably be a Depends.

> Otherwise it is a straightforward package, the only other odd thing
> that is going on is that hugin makes use of autopano-sift which is US
> patent encumbered - I can't add this to fedora and presumably the
> debian situation is the same.

Yep, no serious troubles with it until now. And indeed, the Debian
situation is the very same. I guess you're keeping the libpano
limitation as well for the same reason.

> This is ok as hugin is quite usable without, so there is a short
> informational script that needs to be installed and configured
> instead: utils/autopano-noop.sh
> 
> There comments in that file describing a couple of changes necessary
> to do this configuration.

I was thinking of adding info/pointers about that in the common doc
location that is /usr/share/doc/$package/README.Debian.


A last question, I'm wondering why .so's are shipped under /usr/lib. As
far as I understand it, there are all private libraries, not supposed to
be used by anyone else (no header is shipped), so they might better fit
in /usr/lib/hugin, with an RPATH, don't you think?

Thanks for your comments.

-- 
Cyril Brulebois
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-phototools-devel/attachments/20080128/8221f98e/attachment.pgp