> On 22 Dec, 2016, at 13:04, Baptiste Daroussin <[email protected]> wrote:
>
> The clean way would be to to just have a new variable in a given port that
> describes the possible variations. But that would break all existing external
> tools that deals with the ports tree. Because they all rely on the fact that
> there is a mapping between a package name and an origin (not that pkg does not
> rely on that.
It's more than just cleaner; it improves the development workflow dramatically.
Variable-based flavours can be added, modified, and removed easily. c/p/f may
necessitate recopies and potentially tricky quarterly backports.
Flavours and subpackages are a big deal. I'd prefer that aging,
non-actively-developed not drive design decisions. I feel like the flavour and
subpackage omelettes are worth cracking those eggs for.
> So I decided to go another way: add a third level to the ports tree. So far we
> have category/port and I do propose to add a third level: category/port/flavor
> which will keep the paradigm most tools are expected: 1 packagename == 1
> origin
They're not necessarily redundant: variable-based flavours provide for
combinations of options, and 3rd-level ports provide a meaningful way to
categorize nearly-identical ports (like textproc/aspell/{en,fr}). Personally
I'd love to see both those things happen.
# Adam
--
Adam Weinberger
[email protected]
https://www.adamw.org
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
