> On 22 Dec, 2016, at 13:04, Baptiste Daroussin <b...@freebsd.org> 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
ad...@adamw.org
https://www.adamw.org


_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Reply via email to