> 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"