svn commit: r458161 - head/textproc/meld

[Ben Woods]

On Mon, 8 Jan 2018 at 7:10 am, Paweł Pękala <pawel at freebsd.org> wrote:

> Hi Ben,
>
> On 2018-01-07 01:28 +0000, Ben Woods <woodsb02 at gmail.com> wrote:
> >On Sat, 6 Jan 2018 at 2:17 am, Pawel Pekala <pawel at freebsd.org> wrote:
> >
> >> Author: pawel
> >> Date: Fri Jan  5 18:17:40 2018
> >> New Revision: 458161
> >> URL: https://svnweb.freebsd.org/changeset/ports/458161
> >>
> >> Log:
> >>   - Remove deprecated PYDISTUTILS_INSTALLNOSINGLE by manually setting
> >>     PYDISTUTILS_INSTALLARGS
> >>   - Set USE_PYTHON=noflavors, meld is GUI application and flavors
> >> make no sense here
> >>
> >
> >What about the scenario where the end user is trying to standardise on
> >python 3.4 across there system?
> >
> >With flavors they would have been able to use the default packages to
> >achieve this. Without flavors they either have to live with the fact
> >that another python version will be installed by the official package,
> >or create a custom package repository.
>
> Meld will use python version that is default, it's easy to check via
> command line:
>
> % make all-depends-list | grep python3
> /hdd/ports/lang/python36
>
> % make DEFAULT_VERSIONS=PYTHON3=34 all-depends-list 2>/dev/null | grep
> python3
> /hdd/ports/lang/python34
>
> --
> pozdrawiam / with regards
> Paweł Pękala


Yes, but what if someone only wants to administer their machines with
packages, doesn’t want to rebuild ports, and wants to use a version of
python other than the default?

This is a central idea which flavors helps to solve. It helps sysadmins /
users in avoiding ports and just using packages, whilst still having the
flexibility to decide on a python version if they like.

Regards,
Ben
-- 

--
From: Benjamin Woods
woodsb02 at gmail.com