Solved My first problem with the new "flavor" attitude

P

piggy

I don't know how to handle this:

Code: 
===>>> Returning to update check of installed ports


        ===>>> The devel/py27-setuptools port moved to devel/py-setuptools@py27
        ===>>> Reason: Moved to a flavored, generic, version

===>>> Launching child to reinstall py27-setuptools-36.5.0

===>>> All >> py27-setuptools-36.5.0 (65/65)

        ===>>> The devel/py27-setuptools port moved to devel/py-setuptools@py27
        ===>>> Reason: Moved to a flavored, generic, version
Then:

Code: 
<piggy@freebsd111>/usr/ports/devel # ls py-set*
py-setproctitle:
distinfo  Makefile  pkg-descr

py-setuptools:
distinfo  files     Makefile  pkg-descr

py-setuptools_darcs:
distinfo  Makefile  pkg-descr

py-setuptools_hg:
distinfo  Makefile  pkg-descr

py-setuptools_scm:
distinfo  Makefile  pkg-descr

py-setuptools-git:
distinfo  Makefile  pkg-descr

py-setuptools-pkg:
distinfo  Makefile  pkg-descr
How can I build something that doesn't exist in the ports tree?

Thank you.
 
You need to specify the flavor to use, in your case py27.

This change was done to make things easier.
You specify the python flavor you use (py27) and then you can just install py-setuptools, instead of py712364-setuptools.

This way you do no longer need to be afraid of accidentally installing a wrong python version.
 
Snurg said:
You need to specify the flavor to use, ...
Click to expand...

How do I specify the flavour I want to use? Can I do this system wide? Can I do it for other things like perl, php, apache, the nox versions of the various graphics optional applications?

It it mentioned in the handbook somewhere? I haven't read the handbook (except for the ZFS sections) for about 10 years. I really should, it's a good book.
 
You pass the flavor to the port you want to build: make FLAVOR=py27 install. The default FLAVOR for Python ports is py27 (or py36 if they don't support Python 2.7). So a simple make install in devel/py-setuptools will do as well.

You can check supported flavors for any port with make -V FLAVORS
 
Code: 
20171130:
  AFFECTS: all ports users
  AUTHOR: adamw@FreeBSD.org

  The ports tree has gained "flavors," which are a way to produce multiple
  variations of a port. Some intended examples of this are language
  modules being produced for multiple language versions, and lite/nox11 packages,
  without needing separate ports for each variation. Python ports have already
  been flavored (see the below entry). Flavor support must be added to
  individual ports.

  Flavors are already supported by make, pkg, poudriere, and synth; see the
  manpages for those tools for usage instructions. Portmaster and portupgrade
  don't support flavors yet, but community work on those tools is in progress.

  Some bumps and breakages are inevitable for a major change such as this.
  Please report breakages and monitor the ports@ list for solutions as they
  become available.

20171130:
  AFFECTS: */py*
  AUTHOR: mat@FreeBSD.org

  Ports using Python via USES=python are now flavored.  All the py3-* ports
  have been removed and folded into their py-* master ports.

  People using Poudriere 3.2+ and binary packages do not have to do anything.

  For other people, to build the Python 3.6 version of, for example,
  databases/py-gdbm, you need to run:

    # make FLAVOR=py36 install
See /usr/ports/UPDATING.
 
talsamon said:
ports-mgmt/portmaster with flavor support is landed.
Click to expand...

I'm in the final stages of building FreeBSD 11.1-RELEASE-p4 using ports-mgmt/portmaster to build all the ports I normally install, except itself, and haven't had any problems at all. I didn't have to set any flavor variables at the beginning and straight put it to work compiling ports.

I'm building graphics/gimp now and when that's done only have multimedia/vlc and www/palemoon to go before I'm done compiling ports and am ready to boot to the desktop. It's usually in the area of 550 packages total.

The one thing I did notice was that instead of being able to set all your program options at the beginning of the build and walk away from it without further intervention unless it asks permission to delete a pkg or a problem occurs, program option screens came up all during the builds like they would if you were using # make install clean. This happened regularly during the builds but there were never any problems requiring me to intervene.

This necessitated me having to watch more closely, so I did watch quite a bit of it and saw early on where it was referencing flavors, knew before the build was this far along it was going to go smoothly and fully expect it to finish out that way.

I'll post my build details and a shot later today.
 
Trihexagonal said:
The one thing I did notice was that instead of being able to set all your program options at the beginning of the build and walk away from it without further intervention unless it asks permission to delete a pkg or a problem occurs, program option screens came up all during the builds like they would if you were using # make install clean. This happened regularly during the builds but there were never any problems requiring me to intervene.
Click to expand...
You can circumvent this manually, just run make config-recursive in the port's directory. Make sure you run it a couple of times until it stops showing the config screens. After that everything is configured and portmaster(8) will use the saved configurations.
 
I know pkg is the recommended method to install 3rd party programs, and what will end up taking me about 16 hours could be done in under 1 using pkg, but if you watch what you're doing and read the options screens ports-mgmt/portmaster is pretty easy to use IMO.


Edit: I finished building all my ports including the x11/nvidia-driver-340 and am at the desktop with a final count of 552 programs and no problems during the build.

A big thanks to the new ports-mgmt/portmaster maintainer and everyone who helped get things straightened out with it and ports-mgmt/synth. :beer:
 
i had a similar problem trying to use portmaster to do a security update for OpenEXR, and py27-setuptools is a dependency. it wouldn't update from py27-setuptools-36.2.2 to py27-setuptools-36.5.0. fortunately some people on IRC and then this article woke me up that portmaster has been updated. so i updated portmaster and tried again. many thanks to the new portmaster maintainer, i use this constantly. if i find a link, i will send beer
 
You must log in or register to reply here.
Back
Top