Re: Packaging system suggestion (pkgsrc.org propaganda)

[Michal Pasternak <michal@xxxxxxxxxxxxxxxxxx>]

Joerg Sonnenberger [Sun, Jan 11, 2004 at 06:03:10PM +0100]:
> most current apps. The problem is some apps out there expects that they
> run at the very some location compiled for. That's what makes to temporary
> view idea difficult.

Yea, for example libiconv is one of them (--enable-relocateable option
in configure)

> Basically how difficult would it be to add a
> USE_FAKE option or similiar to specify that this package can be fake
> installed?

Well, depends. If this option would just have to point if package can be
fake installed -- and, if fake install is just installation of this package
somewhere else, than in PREFIX/ hierarchy -- I think you will find only 1%
of currently available packages which can't be installed such way. 

Anyway, as I wrote before -- why this option is so important, why would you
need it? Please understand, I've never used OpenBSD ports -- I have no idea
how fake installs can be useful -- and, as OpenBSD philosophy vs NetBSD -- I
really prefer portabilit over security.

> Consider some big project like XFree86 or perhaps OpenOffice. Ideally
> it should be possible to just install the fonts or the X-Server

You can. Packaged XFree86 is in pkgsrc-wip.sf.net repo.

> or
> StarCalc.

You will be able to do that if you will split openoffice to openoffice-lib
(or openoffice-shared) and openoffice-calc, openoffice-writer... and so on.

> ATM FreeBSD ports handles that by duplicating ports requiring
> multiple builds which is bad.

pkgsrc also duplicated, but it is okay to include Makefile.common (common
settings for a set of packages) in one pkg, then use it in others. See
wip/py-twisted and wip/py-twisted-docs (did by me), see
databases/postgresql/Makefile.common used by databases/postgresql-* for
example

> The loadable plug-ins as pseudo-flavors (my fault) allows us to split
> off a part of the package e.g. the MP3 plugin for XMMS to installed
> separatly.

I think I know what you mean. Have a look at devel/python* packages.
devel/python package simply is a python interpreter, stripped out of some of
its modules, which depend on other 3rd party packages, like bsddb module. If
you want to install py-bsddb module (available via pkgsrc-wip.sf.net), you
also have to get db4 package. So, Python package itself is minimal. Even if
some functionality is included in its standard distro, but depends on other
libraries, it is omited. You use other packages to set it up. 

Same for php. Pkgsrc php, as opposed to "configureable" FreeBSD php, comes
_minimal_. PostgreSQL / MySQL / Ming / XLST support for pkgsrc PHP comes in
other packages, loadable as PHP plugins.

So, if this is what you wanted to be -- yes, pkgsrc supports plugins, and it
is very good at it :)

> The situation becomes
> interesting if some platforms don't support shared libs.

As I neither used nor had chance to test such platform, I can't tell you if
it works as expected -- but yes, pkgsrc contains conditionals for platforms,
that don't support shared libraries (see pkgsrc/mk/* files for details,
especially defs.*)

Anyway, as you keep asking more and more important questions -- and I don't
feel competent enough to provide you good replies, I suggest we take our
future discussion to tech-pkg@xxxxxxxxxxx Some of the things you asked _are_
important features in packaging systems. In case pkgsrc doesn't have them, I
suggest we work and include them in pkgsrc, so it can become ultimate BSD
packaging system, which also will be used in DragonFly :) As I wrote before
-- Matt's fork of FreeBSD was good for BSD community. But, will creation of
another packaging system be?