Re: [HEADUP] FLAVORS landing.

[Philip Paeps]

On 2017-09-26 16:05:08 (+0200), Mathieu Arnold wrote:
**Do not commit FLAVORS to any ports, a hook will prevent it, that 
being said, do try it and test what can be done.**


There also seems to be a hook preventing new py3-* ports being added.

How should maintainers of Python3 ports proceed when their ports have 
new py3-* dependencies?  It's not immediately obvious to me from the 
wiki.


Thanks.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
___
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"

Re: [HEADUP] FLAVORS landing.

[Adam Weinberger]

> On 28 Sep, 2017, at 0:55, Stefan Esser  wrote:
> 
> Am 27.09.17 um 22:57 schrieb Don Lewis:
>> If at some point you run into a bug and need the debug files, you can
>> pkg install the debug files for whatever packages that you need without
>> disturbing your already installed runtime files, and then you can later
>> deinstall the debug files when you are done with them without needing to
>> reinstall the runtime files.  The same thing applies to docs.
> 
> This assumes, that a matching version of the debug files is still
> available. Otherwise, you had to first install the latest version
> of the package and to reproduce the situation with that version.
> 
> This may be seen as a feature (bug reports only for the version
> currently in ports), but may be impractical in many cases.
> 
> The matching of versions of base package and sub-packages must be
> more strict than by version number, since trivial changes might be
> applied to a port without incrementing the PORTREVISION, but with
> impact on the binary, e.g. if the port is to built with some gcc
> version from ports and that gcc port has been updated, leading to
> different object files and debug symbols than a previous version
> of the port with identical version number.
> 
> A "build number" could be added to each (sub-)package and only if
> this build number matches, a sub-package may be installed on top
> of an already installed base package. The build time/date could of
> course be used instead, if an identical value is used for all the
> corresponding files.

Build date/time or some other per-build identifier violates reproducibility.

We already require that PORTREVISION be bumped every time the resulting package 
is changed. We already enforce it universally. Trivial changes, by our 
definition, do not alter the resulting package in any meaningful way (changing 
http to https in the pkg-descr file, improving LICENSE information, etc.).

GCC bump is not in any way a trivial change. When GCC is updated, ALL 
gcc-dependent ports are bumped.

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

Re: [HEADUP] FLAVORS landing.

[Matthew Seaman]

On 28/09/2017 07:55, Stefan Esser wrote:
> The matching of versions of base package and sub-packages must be
> more strict than by version number, since trivial changes might be
> applied to a port without incrementing the PORTREVISION, but with
> impact on the binary, e.g. if the port is to built with some gcc
> version from ports and that gcc port has been updated, leading to
> different object files and debug symbols than a previous version
> of the port with identical version number.

You have a good point here, but I wonder if this scenario would happen
sufficiently frequently to justify making special provision for it in
the package builders.

The vast majority of the ports are compiled with the system C-compiler
-- clang -- and that will not be modified during the lifetime of a
release branch unless directly affected by a Security problem or
Erratum-level bug.  Similarly with the quarterly package branches: ports
versions of compilers will remain stable for 3 months unless directly
affected by a security problem.

Plus a great deal of work has gone into making reproducible builds, so
simply recompiling a port should not introduce any noticeable differences.

If this does prove to be a problem, then presumably the simplest
response would be to bump the PORTREVISION in any port that defaulted to
compiling with the updated compiler, in much the same way that shlib ABI
version bumps are handled.

Failing that, we could do something like introducing a random string
labelled as 'build-id' as a piece of meta-data that gets inserted into
all of the (sub-)packages created out of any one $WRKDIR, and use that
with the existing Provides/Requires mechanism.

Cheers,

Matthew


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

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

Am 27.09.17 um 22:57 schrieb Don Lewis:
> If at some point you run into a bug and need the debug files, you can
> pkg install the debug files for whatever packages that you need without
> disturbing your already installed runtime files, and then you can later
> deinstall the debug files when you are done with them without needing to
> reinstall the runtime files.  The same thing applies to docs.

This assumes, that a matching version of the debug files is still
available. Otherwise, you had to first install the latest version
of the package and to reproduce the situation with that version.

This may be seen as a feature (bug reports only for the version
currently in ports), but may be impractical in many cases.

The matching of versions of base package and sub-packages must be
more strict than by version number, since trivial changes might be
applied to a port without incrementing the PORTREVISION, but with
impact on the binary, e.g. if the port is to built with some gcc
version from ports and that gcc port has been updated, leading to
different object files and debug symbols than a previous version
of the port with identical version number.

A "build number" could be added to each (sub-)package and only if
this build number matches, a sub-package may be installed on top
of an already installed base package. The build time/date could of
course be used instead, if an identical value is used for all the
corresponding files.

Regards, STefan
___
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"

Re: [HEADUP] FLAVORS landing.

[Don Lewis]

On 27 Sep, Julian Elischer wrote:
> On 27/9/17 4:20 pm, Matthew Seaman wrote:
> 
> Before this gets too far down the road I would like to suggest that we 
> quickly formalise some nomenclature
> or we will have 200 different ideas as to how to do the same thing;
> 
> I would like to propose the following possible "examples of official" 
> flavours:
> -nodocs   Â  ..  nearly every port has a DOCS option..  a way to 
> automatically turn it off globally and generate said pkgs would be good.
> -minimal ..  smallest possible feature set.. probably used just to 
> satisfy some stupid dependency.
> -kitchensink    ..  speaks for itself .. options lit up like a 
> christmas tree
> -runtime    ..  no .a files, include files, development 
> documentation or sources ..
>    Â  might only contain a single libxx.so.N file, or a 
> single binary executable.

The docs and runtime would fall into the subpackages category along with
things like debug symbols.

For example, if you want to build a runtime package for port X, and X
has a LIB_DEPENDS that points to Y, then you need to build a version of
Y that contains both the shared library and the include files so that
you can build X.  Since you don't want to install the include files for
Y when you install X, you would have to build another flavor of Y that
doesn't have the include files.  If you use subpackages, you would only
need to build Y once, that that would generate subpackages for the
runtime bits, the include files, the docs, and the debug files.  If you
use something like synth or poudriere for building X, it would install
the runtime and include file subpackages of Y when building X.  When you
want to "pkg install" the X runtime, pkg would only download and install
the Y runtime package.

If at some point you run into a bug and need the debug files, you can
pkg install the debug files for whatever packages that you need without
disturbing your already installed runtime files, and then you can later
deinstall the debug files when you are done with them without needing to
reinstall the runtime files.  The same thing applies to docs.

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

Re: [HEADUP] FLAVORS landing.

[Chris H]

On Wed, 27 Sep 2017 21:24:22 +0800 Julian Elischer  wrote

> On 27/9/17 8:17 pm, Stefan Esser wrote:
> > Am 27.09.17 um 13:52 schrieb Julian Elischer:
> >> On 27/9/17 4:20 pm, Matthew Seaman wrote:
> >>
> >> Before this gets too far down the road I would like to suggest that we
> >> quickly formalise some nomenclature
> >> or we will have 200 different ideas as to how to do the same thing;
> >>
> >> I would like to propose the following possible "examples of official"
> >> flavours:
> >> -nodocs ..  nearly every port has a DOCS option..  a way
to
> >> automatically turn it off globally and generate said pkgs would be good.
> >> -minimal ..  smallest possible feature set.. probably used just to
> >> satisfy some stupid dependency.
> >> -kitchensink    ..  speaks for itself .. options lit up like a
christmas
> >> tree
> >> -runtime    ..  no .a files, include files, development
> >> documentation or sources ..
> >>      might only contain a single
libxx.so.N file, or a
> >> single binary executable.
> > No, these are no good examples for flavours, as I understand them ...
> why not?
> 
> that's part of the problem here. It's not really defined..
> sub packages?  flavours?  what's the difference?
> It's not defined and a dozen examples would go a long way to help.
> I know what I want..  that's to be able to populate my appliance 
> without all the stuff I don't need.
> I also have a different requirement for my application build 
> environment.  There I need all the includes etc.
> How I get there is still a mystery.
If I choose licorice flavor. Do I still get to choose between
red, or black. If not, I'd like to request that black be the
one chosen.
IOW I see your point. I'm not really sure FLAVOR(S) are ready
to land, just yet.

Thanks for bringing this point up, Julian. :)

--Chris
> 
> >
> > These are possible typical sub-package categories, or rather you could
> > remove the DOCS from the base port, but offer a sub-package for them.
> >
> >
> > I'd rather think that NO-X11 might become a typical flavour, or the
> > dependency on a particular crypto library (e.g. openssl vs. libressl).
> >
> >
> > Regards, STefan
> > ___
> > 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"
> >
> >
> 
> ___
> 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"


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

Re: [HEADUP] FLAVORS landing.

[Alexander Leidinger]

Quoting Stefan Esser  (from Wed, 27 Sep 2017 14:35:24 +0200):


Am 26.09.17 um 16:05 schrieb Mathieu Arnold:

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.

This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the
announce and commit and all.

All this information, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.

To define a different flavors in a port, before any include, set:

FLAVORS=  flavor1 flavor2 [...]

The first flavor in the list will be the default.


One question regarding the naming of packages:

The default flavour should probably(?) lead to a package with the same
name as created without flavours.


This implies either an implicit default flavor-name, or stripping of  
the flavor-name in the package-name if it is the first listed flavor.


And if a flavor-ised port gets a different name, shouldn't we  
standardize on the name of the default-flavor (which makes it obsolete  
to list in FLAVORS then)?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpP8XU_Fw0hV.pgp
Description: Digitale PGP-Signatur

Re: [HEADUP] FLAVORS landing.

[Mathieu Arnold]

Le 27/09/2017 à 15:24, Julian Elischer a écrit :
> On 27/9/17 8:17 pm, Stefan Esser wrote:
>> Am 27.09.17 um 13:52 schrieb Julian Elischer:
>>> On 27/9/17 4:20 pm, Matthew Seaman wrote:
>>>
>>> Before this gets too far down the road I would like to suggest that we
>>> quickly formalise some nomenclature
>>> or we will have 200 different ideas as to how to do the same thing;
>>>
>>> I would like to propose the following possible "examples of official"
>>> flavours:
>>> -nodocs ..  nearly every port has a DOCS option..  a way to
>>> automatically turn it off globally and generate said pkgs would be
>>> good.
>>> -minimal ..  smallest possible feature set.. probably used just to
>>> satisfy some stupid dependency.
>>> -kitchensink    ..  speaks for itself .. options lit up like a
>>> christmas
>>> tree
>>> -runtime    ..  no .a files, include files, development
>>> documentation or sources ..
>>>  might only contain a single libxx.so.N file, or a
>>> single binary executable.
>> No, these are no good examples for flavours, as I understand them ...
> why not?
>
> that's part of the problem here. It's not really defined..
> sub packages?  flavours?  what's the difference?

From https://wiki.freebsd.org/Ports/FlavorsAndSubPackages:


  Flavors

One port is built multiple time with variations, each variation creating
a separate package.


  Sub Packages

Build the port once and create multiple packages.



> It's not defined and a dozen examples would go a long way to help.
> I know what I want..  that's to be able to populate my appliance
> without all the stuff I don't need.
> I also have a different requirement for my application build
> environment.  There I need all the includes etc.
> How I get there is still a mystery.
>
>>
>> These are possible typical sub-package categories, or rather you could
>> remove the DOCS from the base port, but offer a sub-package for them.
>>
>>
>> I'd rather think that NO-X11 might become a typical flavour, or the
>> dependency on a particular crypto library (e.g. openssl vs. libressl).
>>
>>
>> Regards, STefan
>> ___
>> 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"
>>
>>
>
> ___
> 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"
>

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Guido Falsi]

On 09/27/2017 15:24, Julian Elischer wrote:
> On 27/9/17 8:17 pm, Stefan Esser wrote:
>> Am 27.09.17 um 13:52 schrieb Julian Elischer:
>>> On 27/9/17 4:20 pm, Matthew Seaman wrote:
>>>
>>> Before this gets too far down the road I would like to suggest that we
>>> quickly formalise some nomenclature
>>> or we will have 200 different ideas as to how to do the same thing;
>>>
>>> I would like to propose the following possible "examples of official"
>>> flavours:
>>> -nodocs ..  nearly every port has a DOCS option..  a way to
>>> automatically turn it off globally and generate said pkgs would be good.
>>> -minimal ..  smallest possible feature set.. probably used just to
>>> satisfy some stupid dependency.
>>> -kitchensink    ..  speaks for itself .. options lit up like a christmas
>>> tree
>>> -runtime    ..  no .a files, include files, development
>>> documentation or sources ..
>>>  might only contain a single libxx.so.N file, or a
>>> single binary executable.
>> No, these are no good examples for flavours, as I understand them ...
> why not?
> 
> that's part of the problem here. It's not really defined..
> sub packages?  flavours?  what's the difference?

While it's not well defined there's a simple euristics which can be applied:

Can two packages be obtained from a single build process of the ports?

yes -> subpackages

this applies when the produced binaries and other parts are the same
with and without a specific option. The only differentiating thing is if
specific files are included or not in the resulting package.

doc/nodoc usually falls in this category.


no -> flavour

this can happen because changing the options actually changes the
produced binaries and the libraries it links too, so I need to build the
port two times with different options.

x11/nox11 usually falls in this category.


There can be grey areas I bet...

-- 
Guido Falsi 
___
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"

Re: [HEADUP] FLAVORS landing.

[Julian Elischer]

On 27/9/17 8:17 pm, Stefan Esser wrote:

Am 27.09.17 um 13:52 schrieb Julian Elischer:

On 27/9/17 4:20 pm, Matthew Seaman wrote:

Before this gets too far down the road I would like to suggest that we
quickly formalise some nomenclature
or we will have 200 different ideas as to how to do the same thing;

I would like to propose the following possible "examples of official"
flavours:
-nodocs ..  nearly every port has a DOCS option..  a way to
automatically turn it off globally and generate said pkgs would be good.
-minimal ..  smallest possible feature set.. probably used just to
satisfy some stupid dependency.
-kitchensink    ..  speaks for itself .. options lit up like a christmas
tree
-runtime    ..  no .a files, include files, development
documentation or sources ..
     might only contain a single libxx.so.N file, or a
single binary executable.

No, these are no good examples for flavours, as I understand them ...

why not?

that's part of the problem here. It's not really defined..
sub packages?  flavours?  what's the difference?
It's not defined and a dozen examples would go a long way to help.
I know what I want..  that's to be able to populate my appliance 
without all the stuff I don't need.
I also have a different requirement for my application build 
environment.  There I need all the includes etc.

How I get there is still a mystery.



These are possible typical sub-package categories, or rather you could
remove the DOCS from the base port, but offer a sub-package for them.


I'd rather think that NO-X11 might become a typical flavour, or the
dependency on a particular crypto library (e.g. openssl vs. libressl).


Regards, STefan
___
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"




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

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

Am 26.09.17 um 16:05 schrieb Mathieu Arnold:
> Hi,
> 
> **Do not commit FLAVORS to any ports, a hook will prevent it, that being
> said, do try it and test what can be done.**
> 
> To test this feature in poudriere, you need
> poudriere-devel-3.1.99.20170621 or later.
> 
> This has been a long awaiting feature, most of the work has been done by
> bapt, bdrewery and antoine, I am just the one actually doing the
> announce and commit and all.
> 
> All this information, and more to come are in the first link to our wiki
> in the bottom block. A roadmap is in the second link.
> 
> To define a different flavors in a port, before any include, set:
> 
> FLAVORS=  flavor1 flavor2 [...]
> 
> The first flavor in the list will be the default.

One question regarding the naming of packages:

The default flavour should probably(?) lead to a package with the same
name as created without flavours.

But any non-default flavour needs a distinct package name.

In the case of the Python ports, this will be the version prefix (py27-
vs. py36-).

But what is planned for the general case?

Will it be left to the port maintainer to add prefixes / postfixes to
package names that reflect the flavours by means of the options that
are enabled by some particular flavour?

Or will the flavour be automatically added to the package name, if
there would be name collisions, otherwise?

Regards, STefan
___
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"

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

Am 27.09.17 um 13:52 schrieb Julian Elischer:
> On 27/9/17 4:20 pm, Matthew Seaman wrote:
> 
> Before this gets too far down the road I would like to suggest that we
> quickly formalise some nomenclature
> or we will have 200 different ideas as to how to do the same thing;
> 
> I would like to propose the following possible "examples of official"
> flavours:
> -nodocs ..  nearly every port has a DOCS option..  a way to
> automatically turn it off globally and generate said pkgs would be good.
> -minimal ..  smallest possible feature set.. probably used just to
> satisfy some stupid dependency.
> -kitchensink    ..  speaks for itself .. options lit up like a christmas
> tree
> -runtime    ..  no .a files, include files, development
> documentation or sources ..
>     might only contain a single libxx.so.N file, or a
> single binary executable.

No, these are no good examples for flavours, as I understand them ...

These are possible typical sub-package categories, or rather you could
remove the DOCS from the base port, but offer a sub-package for them.


I'd rather think that NO-X11 might become a typical flavour, or the
dependency on a particular crypto library (e.g. openssl vs. libressl).


Regards, STefan
___
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"

Re: [HEADUP] FLAVORS landing.

[Guido Falsi]

On 09/27/2017 10:20, Matthew Seaman wrote:


Currently the idea is to work on the python ports in the tree so we'd
have both python-2.7 and python-3.6 versions built and available in the
repos.  That's just the initial target to debug and bed-in the FLAVORS
stuff.


Same applies for php56 vs php70 vx php71 vs phpfutureversions.

Just stating this as a further example.

--
Guido Falsi 
___
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"

Re: [HEADUP] FLAVORS landing.

[Julian Elischer]

On 27/9/17 4:48 pm, Kirill Ponomarev via freebsd-ports wrote:

On 09/27, Tilman Keskinöz wrote:


On 2017-09-27 08:29, Matthew Seaman wrote:

On 27/09/2017 07:11, Julian Elischer wrote:

Is there a document/paper on what this is and what it's limits are etc?

https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
https://wiki.freebsd.org/Ports/FlavorsMigration


These pages don't contain any information what this is, how it differs
from/interacts with the OPTIONS framework and why I would want to
convert a port to FLAVORS.

I'd like to ask portmgr team to provide this information as well as
their vision for future correlations between OPTIONS, FLAVORS and
slave ports.

K.


I second this request.

more clarity in direction is needed.


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

Re: [HEADUP] FLAVORS landing.

[Julian Elischer]

On 27/9/17 4:20 pm, Matthew Seaman wrote:

Before this gets too far down the road I would like to suggest that we 
quickly formalise some nomenclature

or we will have 200 different ideas as to how to do the same thing;

I would like to propose the following possible "examples of official" 
flavours:
-nodocs ..  nearly every port has a DOCS option..  a way to 
automatically turn it off globally and generate said pkgs would be good.
-minimal ..  smallest possible feature set.. probably used just to 
satisfy some stupid dependency.
-kitchensink    ..  speaks for itself .. options lit up like a 
christmas tree
-runtime    ..  no .a files, include files, development 
documentation or sources ..
    might only contain a single libxx.so.N file, or a 
single binary executable.


Other suggestions welcome. These were just suggestions. I await your 
suggestions with interest.


I would certainly like the 'runtime' version as that would allow me to 
create packages for, and populate appliances.


A ports developer would be encouraged to supply as many of the 
official flavours as make sense.

Poudrierre could be taught to generate only "minimal" packages etc.





On 27/09/2017 08:09, Tilman Keskinöz wrote:


On 2017-09-27 08:29, Matthew Seaman wrote:

On 27/09/2017 07:11, Julian Elischer wrote:

Is there a document/paper on what this is and what it's limits are etc?

https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
https://wiki.freebsd.org/Ports/FlavorsMigration


These pages don't contain any information what this is, how it differs
from/interacts with the OPTIONS framework and why I would want to
convert a port to FLAVORS.

Well, you can think of FLAVORS as essentially a group of different
pre-sets for OPTIONS or DEFAULT_VALUE settings, so you can build several
different instances of the same port with different configurations
easily.  It has the biggest benefit for people either using the default
pkg repositories or who are building their own via poudriere or similar.

Currently the idea is to work on the python ports in the tree so we'd
have both python-2.7 and python-3.6 versions built and available in the
repos.  That's just the initial target to debug and bed-in the FLAVORS
stuff.

This will all need to interact with two other changes due to hit the
tree in the not too distant future:

sub-packages --- so from one WRKSRC you can generate several
different packages.  eg. separate packages for doc or examples, a shlibs
package, a devel package with eg. static libraries and headers, a debug
package with separate files for the debugging symbols, as well as the
main package with the principal binaries and so forth.  So, for php,
it's going to make a big change.  Instead of extracting the entire PHP
sources and building each PHP module as a separate job, all of the PHP
modules for a particular version of PHP could be built at once, and the
results just assigned to different packages.

   variable-dependencies --- this should remove one of the biggest
frustrations with the packaging system at the moment, where dependences
are very strict and pkg(8) will insist on installing exactly the version
of any dependencies a package was compiled against.  Frequently this is
unnecessary, as the same package should work fine with eg. a later
version of a dependency, or with an alternate implementation (eg. mysql
vs mariadb).

Overall, it means the repositories will end up containing more packages,
but these will generally be smaller and allow finer grained control of
what gets installed on your system.

The downside at the moment is that tools like portmaster are pretty much
tied to the idea that there is a 1-to-1 relationship between ports and
packages, which this definitively breaks.

Cheers,

Matthew

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




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

Re: [HEADUP] FLAVORS landing.

[Kirill Ponomarev via freebsd-ports]

On 09/27, Tilman Keskinöz wrote:
> 
> 
> On 2017-09-27 08:29, Matthew Seaman wrote:
> > On 27/09/2017 07:11, Julian Elischer wrote:
> >> Is there a document/paper on what this is and what it's limits are etc?
> > 
> > https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
> > https://wiki.freebsd.org/Ports/FlavorsMigration
> > 
> 
> These pages don't contain any information what this is, how it differs
> from/interacts with the OPTIONS framework and why I would want to
> convert a port to FLAVORS.

I'd like to ask portmgr team to provide this information as well as
their vision for future correlations between OPTIONS, FLAVORS and
slave ports.

K.


signature.asc
Description: PGP signature

Re: [HEADUP] FLAVORS landing.

[Matthew Seaman]

On 27/09/2017 08:09, Tilman Keskinöz wrote:
> 
> 
> On 2017-09-27 08:29, Matthew Seaman wrote:
>> On 27/09/2017 07:11, Julian Elischer wrote:
>>> Is there a document/paper on what this is and what it's limits are etc?
>>
>> https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
>> https://wiki.freebsd.org/Ports/FlavorsMigration
>>
> 
> These pages don't contain any information what this is, how it differs
> from/interacts with the OPTIONS framework and why I would want to
> convert a port to FLAVORS.

Well, you can think of FLAVORS as essentially a group of different
pre-sets for OPTIONS or DEFAULT_VALUE settings, so you can build several
different instances of the same port with different configurations
easily.  It has the biggest benefit for people either using the default
pkg repositories or who are building their own via poudriere or similar.

Currently the idea is to work on the python ports in the tree so we'd
have both python-2.7 and python-3.6 versions built and available in the
repos.  That's just the initial target to debug and bed-in the FLAVORS
stuff.

This will all need to interact with two other changes due to hit the
tree in the not too distant future:

   sub-packages --- so from one WRKSRC you can generate several
different packages.  eg. separate packages for doc or examples, a shlibs
package, a devel package with eg. static libraries and headers, a debug
package with separate files for the debugging symbols, as well as the
main package with the principal binaries and so forth.  So, for php,
it's going to make a big change.  Instead of extracting the entire PHP
sources and building each PHP module as a separate job, all of the PHP
modules for a particular version of PHP could be built at once, and the
results just assigned to different packages.

  variable-dependencies --- this should remove one of the biggest
frustrations with the packaging system at the moment, where dependences
are very strict and pkg(8) will insist on installing exactly the version
of any dependencies a package was compiled against.  Frequently this is
unnecessary, as the same package should work fine with eg. a later
version of a dependency, or with an alternate implementation (eg. mysql
vs mariadb).

Overall, it means the repositories will end up containing more packages,
but these will generally be smaller and allow finer grained control of
what gets installed on your system.

The downside at the moment is that tools like portmaster are pretty much
tied to the idea that there is a 1-to-1 relationship between ports and
packages, which this definitively breaks.

Cheers,

Matthew

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

Re: [HEADUP] FLAVORS landing.

[Tilman Keskinöz]

On 2017-09-27 08:29, Matthew Seaman wrote:
> On 27/09/2017 07:11, Julian Elischer wrote:
>> Is there a document/paper on what this is and what it's limits are etc?
> 
> https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
> https://wiki.freebsd.org/Ports/FlavorsMigration
> 

These pages don't contain any information what this is, how it differs
from/interacts with the OPTIONS framework and why I would want to
convert a port to FLAVORS.






signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Matthew Seaman]

On 27/09/2017 07:11, Julian Elischer wrote:
> Is there a document/paper on what this is and what it's limits are etc?

https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
https://wiki.freebsd.org/Ports/FlavorsMigration

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Julian Elischer]

Is there a document/paper on what this is and what it's limits are etc?

On 26/9/17 10:05 pm, Mathieu Arnold wrote:

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.


[...]
___
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"

Re: [HEADUP] FLAVORS landing.

[Pete Wright]

On 09/26/2017 17:43, Mel Pilgrim wrote:

On 09/26/2017 16:56, Greg 'groggy' Lehey wrote:

On Wednesday, 27 September 2017 at 4:39:29 +1000, Andy Farkas wrote:

On 27/09/2017 04:22, Mathieu Arnold wrote:


Please read the whole email.


What are FLAVORS and why do I need it?

Is there somewhere that explains the intent and purpose?


Thank you!  Just the question I was going to ask.


FLAVORS allows a pkg repo to contain variations of the same port. For 
example, a port that has two mutually exclusive options can now exist 
in the public repo as both builds (each with their own FLAVOR suffix), 
rather than requiring the port maintainer select a default and force 
users of the other to compile the port themselves, or do things like 
maintain subports.


thanks for the clarification - this sounds like a really useful feature 
for my workflow at least.  i can actually think of several linux distros 
where something like this would have saved me lots of cycles due to 
having to maintain my own versions (or flavors i guess) of common packages.


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

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

Re: [HEADUP] FLAVORS landing.

[Mel Pilgrim]

On 09/26/2017 16:56, Greg 'groggy' Lehey wrote:

On Wednesday, 27 September 2017 at  4:39:29 +1000, Andy Farkas wrote:

On 27/09/2017 04:22, Mathieu Arnold wrote:


Please read the whole email.


What are FLAVORS and why do I need it?

Is there somewhere that explains the intent and purpose?


Thank you!  Just the question I was going to ask.


FLAVORS allows a pkg repo to contain variations of the same port. For 
example, a port that has two mutually exclusive options can now exist in 
the public repo as both builds (each with their own FLAVOR suffix), 
rather than requiring the port maintainer select a default and force 
users of the other to compile the port themselves, or do things like 
maintain subports.

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

Re: [HEADUP] FLAVORS landing.

[Greg 'groggy' Lehey]

On Wednesday, 27 September 2017 at  4:39:29 +1000, Andy Farkas wrote:
> On 27/09/2017 04:22, Mathieu Arnold wrote:
>
>> Please read the whole email.
>
> What are FLAVORS and why do I need it?
>
> Is there somewhere that explains the intent and purpose?

Thank you!  Just the question I was going to ask.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: [HEADUP] FLAVORS landing.

[Chris H]

On Tue, 26 Sep 2017 16:10:59 +0200 Mathieu Arnold  wrote

> Le 26/09/2017 à 16:05, Mathieu Arnold a écrit :
> > Hi,
> >
> > **Do not commit FLAVORS to any ports, a hook will prevent it, that being
> > said, do try it and test what can be done.**
> >
> > To test this feature in poudriere, you need
> > poudriere-devel-3.1.99.20170621 or later.
> >
> > This has been a long awaiting feature, most of the work has been done by
> > bapt, bdrewery and antoine, I am just the one actually doing the
> > announce and commit and all.
> >
> > All this information, and more to come are in the first link to our wiki
> > in the bottom block. A roadmap is in the second link.
> 
> Of course, I forgot those two links.
> https://wiki.freebsd.org/Ports/FlavorsMigration
> https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
> 
> > To define a different flavors in a port, before any include, set:
> >
> > FLAVORS=  flavor1 flavor2 [...]
> >
> > The first flavor in the list will be the default.
> >
> > You can then check for flavors after includ'ing bsd.port.options.mk with:
> >
> > .if ${FLAVOR} == flavor2
> > [change some stuff]
> > .endif
> >
> > To build flavor2, simply run:
> >
> > make FLAVOR=flavor2
> >
> > To depend on a specific flavor, write @ at the end of the depend
> > string, for example, to depend on flavor "foo":
> >
> > RUN_DEPENDS=    something:origin@foo
> >
> 
From a USER perspective, this is an OPTION, correct?
IOW I would have to specifically ask for it.
I'm just hoping that it's early enough to ensure that FALVOR(S)
are an OPTION not an IMPOSITION.
I would like to suggest that one has to ask for it, before they
can have it. For example; something like one the following in
make.conf(5):

USE_FLAVORS
FLAVORS_ENABLE
HAS_FLAVORS

and it would NOT be a yes/no | true/false -- it is ALWAYS off, and
must be asked for before permitted/enabled.

Make no mistake; I love the flexibility that this [flavors] attempts
to provide. I'm just suggesting this to help prevent (unwelcomed)
surprises. :-)

Thanks!

--Chris

> -- 
> Mathieu Arnold


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

Re: [HEADUP] FLAVORS landing.

[Ernie Luzar]

Mathieu Arnold wrote:

Hi,
snip

All this information, and more to come are in the first link to our wiki
in the bottom block. A road map is in the second link.



There are no links with this email. Do not know what you mean by "our 
wiki". Please be so kind as to provide some links to get us slow people 
on the correct track to come up to speed.


Thank you very much.



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

Re: [HEADUP] FLAVORS landing.

[Matthieu Volat]

On Tue, 26 Sep 2017 10:37:03 -0400
George Mitchell  wrote:

> On 09/26/17 10:05, Mathieu Arnold wrote:
> > [...]
> > This has been a long awaiting feature, most of the work has been done by
> > bapt, bdrewery and antoine, I am just the one actually doing the
> > announce and commit and all.
> > [...]  
> What is the last SVN revision without the changes?  I just updated a
> few minutes ago and portmaster is already unable to build lang/perl5.24
> to fix a security vulnerability. -- George
> 

Indeed, this is *not cool*(tm), especially when an update was *needed* to fix 
some firefox dependancies.


pgpR87VpIj2FH.pgp
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Andy Farkas]

On 27/09/2017 04:22, Mathieu Arnold wrote:


Please read the whole email.



What are FLAVORS and why do I need it?

Is there somewhere that explains the intent and purpose?

-andyf

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

Re: [HEADUP] FLAVORS landing.

[Mathieu Arnold]

Le 26/09/2017 à 20:05, Jan Beich a écrit :
> Mathieu Arnold  writes:
>
>> To build flavor2, simply run:
>>
>> make FLAVOR=flavor2
> What is the default behiavor for simply invoking "make" with no arguments?
> Not building everything (i.e., all flavors) would violate POLA.

Please read the whole email. The answer is a couple of lines before what
you cut.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Adam Weinberger]

Folks, please strip freebsd-ports-announce@ from your Cc's for this thread.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

> On 26 Sep, 2017, at 12:07, Kirill Ponomarev via freebsd-ports 
>  wrote:
> 
> On 09/26, Jan Beich wrote:
>> Mathieu Arnold  writes:
>> 
>>> To build flavor2, simply run:
>>> 
>>> make FLAVOR=flavor2
>> 
>> What is the default behiavor for simply invoking "make" with no arguments?
> 
> I suspect it builds first flavor which is default.
> 
>> Not building everything (i.e., all flavors) would violate POLA.
> 
> K.

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

Re: [HEADUP] FLAVORS landing.

[Jan Beich]

Mathieu Arnold  writes:

> To build flavor2, simply run:
>
> make FLAVOR=flavor2

What is the default behiavor for simply invoking "make" with no arguments?
Not building everything (i.e., all flavors) would violate POLA.
___
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"

Re: [HEADUP] FLAVORS landing.

[Kirill Ponomarev via freebsd-ports]

On 09/26, Jan Beich wrote:
> Mathieu Arnold  writes:
> 
> > To build flavor2, simply run:
> >
> > make FLAVOR=flavor2
> 
> What is the default behiavor for simply invoking "make" with no arguments?

I suspect it builds first flavor which is default.

> Not building everything (i.e., all flavors) would violate POLA.

K.


signature.asc
Description: PGP signature

Re: [FreeBSD-Ports-Announce] [HEADUP] FLAVORS landing.

[Ryan Steinmetz]

On (09/26/17 16:05), Mathieu Arnold wrote:

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.

This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the
announce and commit and all.

All this information, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.

To define a different flavors in a port, before any include, set:

FLAVORS=  flavor1 flavor2 [...]

The first flavor in the list will be the default.

You can then check for flavors after includ'ing bsd.port.options.mk with:

.if ${FLAVOR} == flavor2
[change some stuff]
.endif




Will we have the ability to do something like the following?:

FLAVORS=MYSQL REDIS NOTLS
FLAVOR_MYSQL_OPTIONS_ENABLE= MYSQL
FLAVOR_REDIS_OPTIONS_ENABLE= REDIS
FLAVOR_NOTLS_OPTIONS_DISABLE= TLS

I envision (at least for my ports) this being something very common.

I assume that the current code will already permit us to do something 
like the following:


.if ${FLAVOR} == MYSQL
OPTIONS_DEFAULT+= MYSQL
.endif


-r


To build flavor2, simply run:

make FLAVOR=flavor2

To depend on a specific flavor, write @ at the end of the depend
string, for example, to depend on flavor "foo":

RUN_DEPENDS=    something:origin@foo

--
Mathieu Arnold







--
Ryan Steinmetz
PGP: 9079 51A3 34EF 0CD4 F228  EDC6 1EF8 BA6B D028 46D7
___
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"

[FreeBSD-Ports-Announce] [HEADUP] FLAVORS landing.

[Mathieu Arnold]

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.

This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the
announce and commit and all.

All this information, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.

To define a different flavors in a port, before any include, set:

FLAVORS=  flavor1 flavor2 [...]

The first flavor in the list will be the default.

You can then check for flavors after includ'ing bsd.port.options.mk with:

.if ${FLAVOR} == flavor2
[change some stuff]
.endif

To build flavor2, simply run:

make FLAVOR=flavor2

To depend on a specific flavor, write @ at the end of the depend
string, for example, to depend on flavor "foo":

RUN_DEPENDS=    something:origin@foo

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Vitaly Magerya]

On 09/26/2017 05:38 PM, George Mitchell wrote:
>> What is the last SVN revision without the changes?  I just updated a
>> few minutes ago and portmaster is already unable to build lang/perl5.24
>> to fix a security vulnerability. -- George
> 
> Empirically, 450588 seems to still work. -- George

The first FLAVORS commit is [1], but I think portmaster still generally
works as before. The failure you're seeing with lang/perl5.24 is also
there if you build it manually.

[1] https://svnweb.freebsd.org/ports?view=revision=450663
___
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"

Re: [HEADUP] FLAVORS landing.

[L.Bartoletti]

Great!

Thanks guys!

Loïc


On 26.09.2017 16:10, Mathieu Arnold wrote:

Le 26/09/2017 à 16:05, Mathieu Arnold a écrit :

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.

This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the
announce and commit and all.

All this information, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.

Of course, I forgot those two links.
https://wiki.freebsd.org/Ports/FlavorsMigration
https://wiki.freebsd.org/Ports/FlavorsAndSubPackages


To define a different flavors in a port, before any include, set:

FLAVORS=  flavor1 flavor2 [...]

The first flavor in the list will be the default.

You can then check for flavors after includ'ing bsd.port.options.mk with:

.if ${FLAVOR} == flavor2
[change some stuff]
.endif

To build flavor2, simply run:

make FLAVOR=flavor2

To depend on a specific flavor, write @ at the end of the depend
string, for example, to depend on flavor "foo":

RUN_DEPENDS=    something:origin@foo



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

Re: [HEADUP] FLAVORS landing.

[George Mitchell]

On 09/26/17 10:37, George Mitchell wrote:
> On 09/26/17 10:05, Mathieu Arnold wrote:
>> [...]
>> This has been a long awaiting feature, most of the work has been done by
>> bapt, bdrewery and antoine, I am just the one actually doing the
>> announce and commit and all.
>> [...]
> What is the last SVN revision without the changes?  I just updated a
> few minutes ago and portmaster is already unable to build lang/perl5.24
> to fix a security vulnerability. -- George
> 

Empirically, 450588 seems to still work. -- George



signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[George Mitchell]

On 09/26/17 10:05, Mathieu Arnold wrote:
> [...]
> This has been a long awaiting feature, most of the work has been done by
> bapt, bdrewery and antoine, I am just the one actually doing the
> announce and commit and all.
> [...]
What is the last SVN revision without the changes?  I just updated a
few minutes ago and portmaster is already unable to build lang/perl5.24
to fix a security vulnerability. -- George



signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Mathieu Arnold]

Le 26/09/2017 à 16:05, Mathieu Arnold a écrit :
> Hi,
>
> **Do not commit FLAVORS to any ports, a hook will prevent it, that being
> said, do try it and test what can be done.**
>
> To test this feature in poudriere, you need
> poudriere-devel-3.1.99.20170621 or later.
>
> This has been a long awaiting feature, most of the work has been done by
> bapt, bdrewery and antoine, I am just the one actually doing the
> announce and commit and all.
>
> All this information, and more to come are in the first link to our wiki
> in the bottom block. A roadmap is in the second link.

Of course, I forgot those two links.
https://wiki.freebsd.org/Ports/FlavorsMigration
https://wiki.freebsd.org/Ports/FlavorsAndSubPackages

> To define a different flavors in a port, before any include, set:
>
> FLAVORS=  flavor1 flavor2 [...]
>
> The first flavor in the list will be the default.
>
> You can then check for flavors after includ'ing bsd.port.options.mk with:
>
> .if ${FLAVOR} == flavor2
> [change some stuff]
> .endif
>
> To build flavor2, simply run:
>
> make FLAVOR=flavor2
>
> To depend on a specific flavor, write @ at the end of the depend
> string, for example, to depend on flavor "foo":
>
> RUN_DEPENDS=    something:origin@foo
>

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

[HEADUP] FLAVORS landing.

[Mathieu Arnold]

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.

This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the
announce and commit and all.

All this information, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.

To define a different flavors in a port, before any include, set:

FLAVORS=  flavor1 flavor2 [...]

The first flavor in the list will be the default.

You can then check for flavors after includ'ing bsd.port.options.mk with:

.if ${FLAVOR} == flavor2
[change some stuff]
.endif

To build flavor2, simply run:

make FLAVOR=flavor2

To depend on a specific flavor, write @ at the end of the depend
string, for example, to depend on flavor "foo":

RUN_DEPENDS=    something:origin@foo

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature