Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Dec 2016 09:42:55 +0100
From:      Franco Fichtner <franco@lastsummer.de>
To:        Baptiste Daroussin <bapt@FreeBSD.org>
Cc:        ports@FreeBSD.org
Subject:   Re: HEADSUP: FLAVORS (initial version) and subpackages proposals
Message-ID:  <7B257BA4-DE6C-4726-8CD7-6BC99D856E08@lastsummer.de>
In-Reply-To: <8BED9138-6754-455B-9829-4B9476B795ED@lastsummer.de>
References:  <20161219003143.c2qo5wn3a5kiua3m@ivaldir.etoilebsd.net> <8BED9138-6754-455B-9829-4B9476B795ED@lastsummer.de>

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

> On 20 Dec 2016, at 9:27 AM, Franco Fichtner <franco@lastsummer.de> =
wrote:
>=20
> We shouldn't use "-" or "/" anyway, should we?  Please no fancy things
> like "~" or so.  No arbitrary package names...

To emphasise on this:

A flavour should act as a full replacement of its unflavoured package, =
that
means the package name must be kept.  Only one flavour (or unflavoured)
package can be installed at all times.  As an example:

A weird package "foo" requires "vim", but the user doesn't want to deal =
with
X11, the user should be able to:

# pkg install vim:lite foo

This should not try to change "vim:lite" to "vim".

# pkg install vim

This should be perfectly fine afterwards, too.

Every "vim" should act as "vim", not revoking the integrity of the =
package
dependency on vim during e.g. pkg upgrade.  No forced install should be
needed to do this as long as the shared libraries and dependencies are =
still
satisfied.  And maybe the moral of the story is that flavours should not
be depended on by default, although it could be a possibility for =
special
cases.

This is something that is really really needed.  An very good example =
would
be Suricata package with Hyperscan right now, where Hyperscan does not =
work
on all amd64 architectures, so we need to have a replacement package.  =
But
if that replacement package without Hyperscan needs to be a separate =
port,
any package depending on Suricata (e.g. a distribution or GUI package) =
will
complain about the missing dependency and try to undo a =
Suricata-No-Hyperscan
package[1] as it conflicts and changes back to the defunct package on =
upgrade.


Cheers,
Franco

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210490=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7B257BA4-DE6C-4726-8CD7-6BC99D856E08>