On Tue, Dec 20, 2016 at 10:12:04AM +0100, Franco Fichtner wrote:
> And lastly... if we have the automatic "default" flavour that is
> defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
> upgrading custom builds by knowing that somebody built a "custom"
> version of their port and that there is no equivalent to upgrade
> to.
>
> This is exciting!
While it is exciting, I would be sad to see flavours be the solution to
pkg not recognizing build OPTIONS_ as part of a package's identity
right now[1].
What is not entirely clear to me:
Are flavours always a tuple of values for OPTIONS_ defined by their
master port?
The reason I bring this up: a binary package is identified by the
following information:
- pkg name (the master's name, unique over ports tree)
- version & revision
- the artifacts used to build the binary
(tarballs, but also build dependencies, ...)
- a vector of available options
- a vector of values for the available options
- (other stuff you could probably find in a talk on reproducible
builds)
It is obvious that a master port will have *many* binary incarnations.
To my understanding, flavours are a comfortable way to write down some
commonly used incarnations.
Reducing the package manager's job to checking that some incarnation of
the package is present is surely better than no support for this.
However, I think the logical next step is to have ports declare that
they depend on a subset of specific configuration values being used in
their dependencies.
In this scenario, flavours are no different to pkg than self-built
ports with custom-picked non-(flavour|standard)ized options.
This, I would very much prefer.
Either way: big thanks to bapt and those who contributed so far!
-- Christian
[1] Please continue reading for what I understand as 'package identity'.
_______________________________________________
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"
