Re: Debian packages

2006/11/12, Philip Van Hoof <spam pvanhoof be>:
On Sun, 2006-11-12 at 11:32 +0100, Øystein Gisnås wrote:

> I like your idea of splitting libraries into separate package for
> flexibility, but I don't think it's possible to run tinymail-gtk
> without libtintymail-mozembed if it was compiled with -gtkhtml or
> without html support. That is only possible with plugin style modules
> like the camel providers.

If tinymail was compiled with --with-html-component=none, then tinymail
will run without libtinymail-mozembed. Else tinymail will indeed require
(and link with) the selected HTML component's library.

> Another problem is that the set of packages from one source must be
> compiled in one "run". For example -mozembed and -gtkhtml can't both
> be compiled unless the build scripts (,
> allow it.


> The good news is that as long as platform features are autodetected by
> the configure script, packages can in theory be compiled without
> modification on a different Debian-based platform.

Yes. I was thinking about making it easy for a packager to configure
your package-work in such a way that they would build a correct series
of packages for them (which packages to build, would depend on that

For example a m4 or script that generates it. Or
configuration switches or a configuration file in "debian/" etcetera.

Let the goal be to make the packaging scripts the best starting point
for someone that want to customise and package for their platform more
than aiming for desktop users. I'm not sure if it's worth it to use m4
or other kind of scripts to create the package scripts. As long as the
autotools build scripts are sane, the amount of customisation in the
debian scripts will be minimal. Any potential packager will be able to
edit debian/rules and modify for example
--with-html-component=mozembed to =gtkhtml anyway.

For desktop usage, a specific series of components can probably be
built. But for mobile devices the developers are going to pick which
components and implementations they will want to use.

For example they will pick a libtinymail-gtkhtml or a
libtinymail-mozembed whereas on a desktop, maybe they will care less
about that.

Not only packages suffers from this difficulty. The bindings also do. I
had to create (and generate things for the) python bindings depending on
the selected platform specific library.

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