Re: Platform ports vs. multiplatform

Hi,

> > yes, but at least according to debian/ubuntu build rules, that
> > doenst seem to be enough. (debian's rule file is over 3k LOC)
>
> Ah - that does seem a tad unfortunate. I'm sure there are lots of
> good things in debian's rules file that we could fold into the core and
> make easier for distributors in an incremental fashion. Having not read
> the file - I've no concrete ideas there :-) but ... at least looking at
> how some of our .spec files re-order and re-group the scp2 break-down to
> get the packaging prettier lots could be improved in that bit alone.

One thing we, IMHO, should do is splitting the whole thing into smaller
parts, eg. building extensions or helpcontent out of tree, moving them
to their completely own packages. That would make packager's life much
easier.

Another front is 3rdparty libraries. Optimally, as a packager, you want
it to get its deps entirely from the system (or sysroot) - without
having to tweak a lot of parameters - and _never_ let it download
anything. Packaging then needs to run entirely through the distro's
machinery.


OTOH we've got platforms that don't know the concept of distros and
package management/repositories.

My approach to this is: having a separate 'workspace' system for handling
all the things that usually distro build machines would do. Esentially
rolling an own micro-distro (or multiple ones for several platforms).

Such an micro-distro, eg. for win32/cygwin, would do things like:

* proper toolchain setup, at least check if everything's correct,
  and guide the user through the setup (if it can't be done automatically)
* deploy cygwin build environment and maybe pull in required packages
* build missing dependencies (not yet in cygwin repos) and deploy them
  into the build environment
* maybe provide some user friendly buildtime configuration (perhaps something
  windows-friendly counterpart of linux kernel's 'make menuconfig' ?)
* build lo itself
* create deployable packages (cygwin, msi, ...) install program (which
  maybe would just be a little wrapper around msi)

Similarily, there could be such an 'workspace' for Debian+friends, which:

* makes sure all required packages are installed (via apt-get calls)
* builds the missing 3rdparty libs (that aren't in debian yet) into
  their own prefix (eg. /usr/lib/libreoffice/depend/), packaging to
  something like 'libreoffice-libraries', adding it to local aptrepo
* drive the package build, w/ --with-system-*, adding proper pkg-config
  pathes and build proper deb packages
* runs all package builds via pbuilder+friends

> > > --disable-epm  ?
> >
> > I'm talking about dropping it completely in my branch.
> > By the way: what is this actually used for ? Not sure about the
> > other distros, but Debian+friends dont seem to use it.
>
>       Oh; EPM is used to build the generic cross-distribution packages
>       that we ship for Linux.

Well, to have it really generic, you'll need to link statically against
all libraries normally found on operating systems, down to libc. This
leads to an huge increase in diskspace and memory consumption.
Another drawback is that bugfixes (esp. security-related!) coming from
their distro.

I'd consider that as a workaround if you _really_ need very recent
versions that aren't distro-packaged yet.

At this point, I'd seriously raise the question why distros lag behind
so far that people get interested in such an cross-dist package.


cu
--
Mit freundlichen Grüßen / Kind regards

Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weigelt@vnc.biz; www.vnc.de