Hi all, I've seen there was already some discussion about the FLAVOR feature. Now it seems to hit me.
Somewhere ShelLuser wrote:
It's not quite that easy. Indeed it is quite difficult.
When I update the portstree (once a year, or so), I do the following [1]:
1. List all ports installed on a system.
2. Get all dependencies for all of these ports (make all-depends-list)
3. Sort all these dependencies into a hierarchy (what depends on what?)
4. Build the whole stuff in that proper sequence.
5. Update the respective system from the resulting packages, and all proper dependencies are now available.
This worlks as trouble-free as installing from packages, but it works with my settings in make.conf and with my patches in the ports.
But now, e.g. firefox tells me it somehow depends on [PMAN=]devel/py-setuptools[/PMAN]. So I ask
Now, I could proably declare in make.conf "I want to go with (e.g.) py35, only". But that does not work, because firefox depends on some pieces that need python2 and some that need python3.
In the past this was sorted out, because each of these pieces would declare it's own dependencies uniquely. Now they all declare "devel/py-setuptools", and it is ambigous, and I don't see how that could be sorted out, except manually for each case.
I could also build all four of them, but there is no point, because some of them are probably conflicting to each other - they can be individually built, but not installed together before building firefox.
I suppose the FLAVOR thing is a good thing, and it can solve problems. (Indeed, the creepy "slave ports" were a nuisance.) But at this point, it seems, it blows up my scheme altogether, and currently I don't see how to devise a new scheme.
[1] I do this partly with portupgrade and partly with own scripts (the parts where portupgrade has not proven reliable enough to cleanly rebuild a whole desktop and me to go for a sleep in the meantime). Probably, meanwhile I could drop portupgrade alltogether and do it just with make.
Somewhere ShelLuser wrote:
I don't understand the confusion. [...] See, the whole FLAVOR thing is merely a make specification. Nothing different from, say, BUILD_OPTIMIZED=yes or DISABLE_VULNERABILITIES=yes.
And if you need to use those permanently, then simply define them globally. So: using /etc/make.conf. Problem solved. ((edit): note that I don't recommend setting DISABLE_VULNERABILITIES within /etc/make.conf).
It's not quite that easy. Indeed it is quite difficult.
When I update the portstree (once a year, or so), I do the following [1]:
1. List all ports installed on a system.
2. Get all dependencies for all of these ports (make all-depends-list)
3. Sort all these dependencies into a hierarchy (what depends on what?)
4. Build the whole stuff in that proper sequence.
5. Update the respective system from the resulting packages, and all proper dependencies are now available.
This worlks as trouble-free as installing from packages, but it works with my settings in make.conf and with my patches in the ports.
But now, e.g. firefox tells me it somehow depends on [PMAN=]devel/py-setuptools[/PMAN]. So I ask
make describe
for the proper name to build, and I get four answers:
Code:
py27-setuptools devel/py-setuptools
py34-setuptools devel/py-setuptools
py35-setuptools devel/py-setuptools
py36-setuptools devel/py-setuptools
Now, I could proably declare in make.conf "I want to go with (e.g.) py35, only". But that does not work, because firefox depends on some pieces that need python2 and some that need python3.
In the past this was sorted out, because each of these pieces would declare it's own dependencies uniquely. Now they all declare "devel/py-setuptools", and it is ambigous, and I don't see how that could be sorted out, except manually for each case.
I could also build all four of them, but there is no point, because some of them are probably conflicting to each other - they can be individually built, but not installed together before building firefox.
I suppose the FLAVOR thing is a good thing, and it can solve problems. (Indeed, the creepy "slave ports" were a nuisance.) But at this point, it seems, it blows up my scheme altogether, and currently I don't see how to devise a new scheme.
[1] I do this partly with portupgrade and partly with own scripts (the parts where portupgrade has not proven reliable enough to cleanly rebuild a whole desktop and me to go for a sleep in the meantime). Probably, meanwhile I could drop portupgrade alltogether and do it just with make.