Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Oct 2012 00:25:53 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Patrick Lamaiziere <patfbsd@davenulle.org>
Cc:        ports@FreeBSD.org
Subject:   Re: future of packages?
Message-ID:  <20121009222553.GH8713@ithaqua.etoilebsd.net>
In-Reply-To: <20121010001723.0e75efb2@davenulle.org>
References:  <20121010001723.0e75efb2@davenulle.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--YrlhzR9YrZtruaFS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2012 at 12:17:23AM +0200, Patrick Lamaiziere wrote:
> Hello,
>=20
> I have to say that I'm convinced that pkg and packages is the way
> to go. It is nice to have a package manager (pkg is a wonderfull
> tool), but without package, such tool is a bit useless...
>=20
> So which packages? IMO packages should be consistent (by example if we
> support ipv6, all packages should have "ipv6 on" option). But this is
> also true for, by example ldap: should we provide ldap authentifcation
> by default? (IMO yes since FreeBSD targets servers).=20
>=20
> A "generic" packages set also means that a lot of things (into
> packages) will be useless (I'm sure some pleople will complain). But it
> will be the cost to use packages.
>=20
> IMO it will take a lot a time to have a consistent options set for our
> packages. It could be a bit premature, but I will be to happy to ear
> about how packages and packages options will be handle in the future.

Lot's of things are possible:
1/ with pkgng 2.0 we expect to be able to get provides/requires features,
which could help a lot having packages build with
different options and no dependency problem (can be seen as kindof flavours)

2/ an other direction, would be to be able to split packages: aka one port =
to
provide multiple packages, most (not all) of the time the options in ports =
are
only there to add files/libs or not into a package if we can split packages=
 then
we can drastically reduce the number of options

3/ sane package splitting, I know there is a lot of people that will not be
happy with the next, but being able to split packages into runtime vs
development part for example can help a lot, for example, allowing having
packages depending on mysql41 runtime libraries and mysql42 runtime librari=
es
install at the same time with no conflicts, lots of different version of sa=
me
libraries conflicts just because they are pulling the same developpement fi=
les,
which end-users don't care about.

regards,
Bapt



--YrlhzR9YrZtruaFS
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlB0pHEACgkQ8kTtMUmk6EyUbgCfYrR3hs27x4NiRqwxIyAiBYpN
NSwAn24Cb9JniRWIbGTrYeMwki1vqpqo
=jiCX
-----END PGP SIGNATURE-----

--YrlhzR9YrZtruaFS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121009222553.GH8713>