Working on FLAVOR support in portmaster

[Milan Obuch]

On Tue, 5 Dec 2017 08:35:55 +0100
Stefan Esser <se at freebsd.org> wrote:

> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
> > By the way, where is the clever way to update to flavor?
> > I am using portmaster.  
> 
> I'm working on FLAVOR support in portmaster. My version did already
> build all updated ports, the FLAVOR parameter is passed to build
> sub-processes, but there is still some confusion between multiple
> flavored versions of the same port (installing the py27 version wants
> to deinstall the py36 version and vice versa), which I still have to
> fix.
>

Thank you! Great news.

> I'm not sure that I have time to complete the fix today, but it is
> not too hard. Ports need to complement the port origin with the
> FLAVOR, where appropriate (e.g. when a flavored destination is found
> in MOVED). Already installed packages are annotated with "flavor" and
> that must be passed to the build command, when that port is updated.
> Most other logic in portmaster remains unaffected.
>

As I understand it, portmaster is kind of wrapper around ports
infrastructure. What makes it complicated is a good number corner cases
which are not easy to handle right.

In my experience, even unaltered still kind of works for me with recet
port tree. I did even upgrade some python ports with it, so chances are
it could be done.

> My work version has all non PKG_NG support stripped, but that is
> mainly to not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package
> system? AFAIK, there is no way that a modern ports tree with flavor
> support works with a non-PKG_NG infrastructure?
> 

This is not easy to tell... Is there still interest in old pkg_tools?
In my opinion, old pkg_tools should be in history (and I know I did use
them as long as it was kind of working before moving to current pkg).
How much of portmaster code deals with this legacy tools? Removing this
code could have positive effect of less code to deal with means less
space for bugs... Or portmaster-legacy port could be created, if there
is real interest.

Regards,
Milan