Bug 236054 - sysutils/py-salt : update to 2019.2.0
Summary: sysutils/py-salt : update to 2019.2.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ben Woods
Keywords: patch, patch-ready
Depends on:
Reported: 2019-02-26 13:49 UTC by Christer Edwards
Modified: 2019-05-18 18:25 UTC (History)
3 users (show)

See Also:

patch (2.16 KB, patch)
2019-02-26 13:49 UTC, Christer Edwards
woodsb02: maintainer-approval+
Details | Diff
poudriere testport (sysutils/py-salt@py27) (638.74 KB, text/plain)
2019-02-26 13:50 UTC, Christer Edwards
no flags Details
poudriere testport (sysutils/py-salt@py36) (654.70 KB, text/plain)
2019-02-26 13:50 UTC, Christer Edwards
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christer Edwards 2019-02-26 13:49:27 UTC
Created attachment 202381 [details]

This patch updates sysutils/py-salt to 2019.2.0.

Upstream release notes:
Comment 1 Christer Edwards 2019-02-26 13:50:19 UTC
Created attachment 202382 [details]
poudriere testport (sysutils/py-salt@py27)
Comment 2 Christer Edwards 2019-02-26 13:50:42 UTC
Created attachment 202383 [details]
poudriere testport (sysutils/py-salt@py36)
Comment 3 commit-hook freebsd_committer 2019-02-27 15:06:09 UTC
A commit references this bug:

Author: woodsb02
Date: Wed Feb 27 15:05:34 UTC 2019
New revision: 494060
URL: https://svnweb.freebsd.org/changeset/ports/494060

  sysutils/py-salt: Update to 2019.2.0

  Changes this release:

  PR:		236054
  Submitted by:	Christer Edwards <christer.edwards@gmail.com> (maintainer)

Comment 4 Ben Woods freebsd_committer 2019-02-27 15:06:22 UTC
Committed - thanks!
Comment 5 ari 2019-02-27 23:58:54 UTC
Can we please split this port into -devel and stable versions? 2018.3.4 was also released this week and is a much more appropriate upgrade for most users right now. Saltstack have a poor reputation for releasing very buggy updates, particularly major releases. They do minimal testing on FreeBSD so almost every update has major regressions.

Can we split this port if you really want to move to cutting edge versions which haven't yet gone through a beta process?
Comment 6 Ben Woods freebsd_committer 2019-02-28 00:09:21 UTC
Hi ari,

I don’t think it would be fair to call this a -devel release, as it is the latest stable release from upstream.

You already have the option of using a more stable version, by using the ports quarterly branch, but obviously that means “more stable” versions of ALL ports. I personally feel the latest minor release of salt should always be updated to the quarterly branch.

It could be possible to have a py-salt-latest port, and a py-salt-stable port, but it doubles the overhead of maintaining the port. Up to the maintainer really.
Comment 7 ari 2019-02-28 00:35:06 UTC
I've been through this journey with salt for four years now. I can pretty much put money on 2019.2.0 being at best beta quality.

The problem with tracking the latest builds days after release is that we never get the opportunity to use 2018.3.4 which will be a much  better experience for everyone. Personally I don't mind since we'll cut our own port, but I want salt to be popular and for people not to give up after hitting problems.

Current critical bugs: https://github.com/saltstack/salt/issues?q=is%3Aopen+is%3Aissue+label%3A2019.2.1  and its only been 48 hours.

One major release they broke pkgng on FreeBSD. Another they broke prereq dependency management.

Even waiting for 2019.2.1 would be a big help.
Comment 8 Christer Edwards 2019-02-28 00:42:15 UTC
I tend to agree with Ari.

SaltStack's lack of testing on FreeBSD has been a thorn in my side since submitting the port in 2011. Believe me, I've talked to them about it (their HQ is local to me). They don't believe there is a commercial market on *BSD and simply don't want to expend resources for it.

It's disappointing.

I will create a port to track latest and stable. Ben, please verify what the preferred portname would be. -devel? -latest? -stable? With that info I'll work on a new port that tracks 2018.3.x.
Comment 9 Ben Woods freebsd_committer 2019-03-02 00:13:11 UTC
One option is to have multiple ports called:

Which version is used by packages which depend on salt would be defined in the ports make.conf variable DEFAULT_VERSIONS= salt=2018.3

These would follow the upstream salt support lifecycle, and be deprecated and delted once “phase 3” support is ended:

Comment 10 ari 2019-03-04 01:21:19 UTC
That approach seems good and consistent with ports like https://www.freshports.org/www/apache24 and with their current policy it would appear that they are likely to have only 2-3 'live' versions at once.
Comment 11 Christer Edwards 2019-03-04 04:28:06 UTC
I've started work on this.

sysutils/py-salt20183 will be py27 only.
sysutils/py-salt20192 will be py27/py36.

I plan to do some more testing tomorrow and hopefully have a patch in day or two.
Comment 12 ari 2019-03-04 04:45:32 UTC
Nice. I don't think you need to pull python36 from 20183. We've been using that combination for at least 6 months without issue.
Comment 13 TAO ZHOU 2019-03-12 23:58:44 UTC
salt 2018.3.x is quite stable with py36. It would be nice to have both with sysutils/py-salt20183 too.
Comment 14 Christer Edwards 2019-05-18 18:25:44 UTC
This port-split has been submitted in bug #237971.