Re: [MacPorts] #15712: Add versions to platforms

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by raimue):

 Replying to [comment:21 mojca]:
 > I would really like to see the ability to proliferate this information
 from PortGroups or potentially even dependencies. If one port depends on
 `qt5` which cannot be compiled on older systems, then this port (or any
 other dependent port of `qt5`) should have those darwin versions
 blacklisted as well.

 I agree the platform information should be used early in a `port install`
 and error out before even installing dependencies. But in my opinion, this
 is out of scope of defining a syntax for `platforms`.

 I am still not convinced of the `-blacklist`/`-whitelist` approach. What
 if I only specify a whitelist? Would it imply all other versions are not
 supported?

 Also, consider this example:

 {{{
 platforms-blacklist {darwin >= 10}
 platforms-whitelist {darwin 11}
 }}}

 Of course this is an artificial example, but the syntax supports it. You
 said start with whitelist, then apply blacklist. So, the blacklist
 overrides `{darwin 11}` in the whitelist and it is not supported? Or is
 `{darwin 11}` supported although it is matched by the blacklist?
 Implementing and documenting this behavior seems complicated and overly
 complex.

 With a `platforms` option taking entries for supported platforms as
 [#comment:20 as proposed above], there is no room for ambiguity:

 {{{
 platforms {darwin < 10} {darwin 11}
 }}}

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:23>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by pmetzger):

 Side note: The OCaml OPAM people have a pretty rich language for
 specifying versions for platforms and dependencies. I'm not sure their
 syntax is worth stealing, but the ability to say things like "this
 requires a dependent package or platform not less than X in version and
 not greater than Y" is kind of cool. (When I work with opam, I long for
 many things that are built in to macports, and when I work with macports,
 I long for things built in to opam. opam's ability to specify versioning
 nicely is such a feature.)

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:24>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by ryandesign):

 Perry, can you show us specifically what that syntax looks like, or
 provide a link to its documentation?

 What we implement for MacPorts will be constrained by what makes sense in
 Tcl.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:25>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by pmetzger):

 Link to the documentation below. I stole these examples from the web site.
 The syntax they use probably isn't feasible to steal for Tcl, but some of
 the ideas might be interesting to steal.

 Typically, you specify a package dependency constraint like:

 {{{
 "pkg1" {>= "3.2" & != "3.7"}
 }}}

 They can constrain multiple packages, eg:

 {{{
 ("pkg1" & "pkg2") | "pkg3" {>= "3.2" & != "3.7"}
 }}}

 You constrain where your package is available with separate constraints
 described in stanzas like this:

 {{{
 available: [ os != "darwin" | ocaml-version >= "4.00" ]
 }}}

 They can also do things like constraining individual arguments to build
 commands based on version constraints, like:

 {{{
 ["./configure" "--with-foo" {ocaml-version > "3.12"} "--
 prefix=%{prefix}%"]
 }}}

 which will only include --with-foo in the command for 3.12 and above.

 [https://opam.ocaml.org/doc/Manual.html Full Manual.]

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:26>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by pmetzger):

 Oh, one other example from the manual:

 {{{
 "foo" { >= "3.12" } & ("bar" | "baz" { !(> "2" & < "3.5") & != "5.1" })
 }}}

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:27>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by mojca):

 Rainer, yes, in your example above I would consider all platforms
 blacklisted. If you don't like "whitelisting" (you could call it
 `platforms-blacklisteverythingbut` :), we can drop it. My idea only needs
 blacklisting to work.

 Now, to explain why your suggestion might be tricky to implement and
 understand, imagine that your port declares
 {{{
 platforms {darwin < 10} {darwin 11}
 }}}
 and one the portgroup it includes declares
 {{{
 platforms {darwin > 10}
 }}}
 and one dependency would declare
 {{{
 platforms {darwin > 12}
 }}}
 etc. How do you then combine these together? Users might just as well
 start thinking of using something like `platforms-append {darwin 13}`

 How will you determine whether the port can be installed on a particular
 platform? You would need to use cross-sections of options which is not
 quite easy for users to understand either.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:28>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by raimue):

 You would have to use `platforms-append` like we do for any other option
 that comes from PortGroups. Why would we want to handle `platforms`
 differently than other options?

 {{{
 # PortGroup ...
 platforms {darwin > 10}

 # Portfile
 platforms-append {darwin < 10} {darwin 11}
 }}}

 Overall, we mostly care whether the current platform is supported or not.
 There is no need for complicated blacklists or whitelists. There is
 usually only a need to express a maximum or minimum version requirement
 for each platform.

 To find out if the current platform is compatible, we walk through this
 full list of requirements as explained [#comment:20 above]. We check each
 item of this list (`{darwin > 10} {darwin < 10} {darwin 11}`) against the
 current platform.

 Let me write some pseudo-code for the algorithm:

 {{{
 state = MAYBE
 foreach item in $platforms
     supported = check_if_supported(current_platform, current_version,
 item)
     if supported == YES
         state = YES
     else if supported == NO
         if state == MAYBE
             state = NO
         endif
     else
         // MAYBE is ignored
     endif
 endforeach

 define check_if_supported(current_platform, current_version, item)
     platform, operator, version = split(item)
     if current_platform != platform
         return MAYBE
     endif
     if current_version operator version    // think of: 1.5 < 2.0
         return YES
     else
         return NO
     endif
 enddefine
 }}}

 If we end with `state == NO`, the current platform is definitely not
 supported. If we end with `state == MAYBE`, this build might work and we
 warn the user, but continue. If we end with `state == yes`, we obviously
 just continue.

 The example list from above would always evaluate to `YES` on macOS except
 for `darwin 10` (or `darwin 10.0.0`, depending on how we compare the
 version).

 I do not see a use case when you would need to broaden the list of
 supported versions later. If a PortGroup says that it requires `darwin <
 10`, under what circumstances would the port need to say that an older
 version is actually supported? Then the requirement in the PortGroup was
 likely bogus and needs to be fixed. And even then, you can still override
 it in the Portfile by just using `platforms` (without `-append`) or delete
 the specific item with a `-delete` or `-replace`. It is just like any
 other option.

 I do not understand why you also bring dependencies into this... They can
 declare whatever they want and yes, it might stop us from installing
 dependents. But this has no influence on the way we specify `platforms` in
 this port. We will check whether the current platform is supported each
 time we want to install ports, so we automatically do it for the
 dependency. If it does not support it, we stop at this point and all the
 dependents cannot be installed. To give an appropriate error message we
 have to evaluate this for each port separately anway, so I do not see when
 we would have to merge anything.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:30>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by mojca):

 Replying to [comment:30 raimue]:
 >
 > The example list from above would always evaluate to `YES` on macOS
 except for `darwin 10`

 See, that's where we completely disagree. The point of my example above is
 that the PortGroup specifying
 {{{
 platforms {darwin > 10}
 }}}
 means that a dependency (like Qt or wxWidgets or so) cannot be compiled on
 Snow Leopard or earlier, while (sorry for a not too realistic example) the
 following code in the Portfile
 {{{
 platforms {darwin < 10} {darwin 11}
 }}}
 means that the code in that port either requires some ancient SDK or no
 longer compiles with a newer compiler.

 The message I want to convey is that a PortGroup specifying `{darwin >
 10}` should not mean that a port using that PG can **additionally**
 (unconditionally) be compiled on any OS 10.7 or newer. It should mean that
 the port **cannot** be compiled on 10.6 and lower under any circumstances.
 Like the latest version of Qt.

 You are doing union. I claim we should be doing cross-section on compiler
 selection, else specifying any platforms in the PortGroup will be
 completely useless. This is why I consider blacklisting a better option.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:31>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by mojca):

 OK, we might not need to merge the lists with dependencies, but we do need
 to make sure that multiple PortGroups included in the same port could
 specify that the port cannot be built on some platforms.

 Building `gnuplot +qt` will certainly have different coverage of supported
 platforms than `gnuplot -qt` or `gnuplot +wxt`.

 Then again ... if we evaluate dependencies separately anyway, if a port
 includes qt5 PG and that one pulls in dependency on qt5 anyway, the PG
 might not actually need to blacklist any platforms since the platform will
 already be blacklisted by qt5 itself.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:32>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by raimue):

 What did you expect as result for the example? Should it be supported on
 `darwin 11` or not? And why would it not be supported on `darwin 10`? I am
 confused by your description.

 Okay, I understand your point now that it should be allowed to add more
 restrictions. This is indeed not possible with my proposal.

 Replying to [comment:32 mojca]:
 > Then again ... if we evaluate dependencies separately anyway, if a port
 includes qt5 PG and that one pulls in dependency on qt5 anyway, the PG
 might not actually need to blacklist any platforms since the platform will
 already be blacklisted by qt5 itself.

 Exactly this is what I was trying to say. We do not need to care about
 dependencies, we only need to specify what *this* port supports.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:33>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by ryandesign):

 It was said at one point that implementing this type of restriction on
 whether a port can build or not (whether it's based on OS version or other
 criteria) could not be done until we had merged the GSoC '15 libsolv
 branch. Do we still think that's a requirement, or no?

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:34>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by raimue):

 We can certainly check whether the current platform is supported when
 trying to install a port. This would be the same what we already do for
 `supported_archs`.

 However, checking the whole dependency tree before attempting to install
 any port, even any dependency, should only be attempted with the libsolv
 branch as that inherently collects the whole dependency tree first.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:35>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by mojca):

 Just to "defend" myself a bit. My "frustration" with blacklisting comes
 from the compiler background. Assume port `foo` which cannot be built with
 the latest compiler & macOS 10.13, providing two non-conflicting
 variantes, `+qt5` (or `+qt4`) and `+wxwidgets`. This particular port would
 generally only blacklist that particular compiler and specify that it
 cannot be built on 10.13.

 Both `qt5-base` and `wxWidgets` have their own set of defunct compilers
 and unsupported macOS versions.

 Now, `wxWidgets` gets upgraded to a newer version after which it no longer
 compiles with `clang 425`. This means that `foo` and all other ports
 depending on `wxWidgets` need to have an additional compiler blacklisted.
 This information does not proliferate from one port to another (from
 dependencies), so all the compiler blacklisting needs to be done inside
 the PortGroup. At the moment we would have three compiler blacklistings:
 for `foo`, for `wxWidgets` and for `qt5`. Only compilers (and OSes) that
 have not been blacklisted anywhere should "survive" after both PortGroups
 have been included.

 I initially failed to realize that blacklisting OS versions can be done in
 an easier way since the system should be designed in a way that will not
 allow installing any port that depends on something that's not supported
 on this platform. That is: it's not necessary to blacklist OSes inside the
 `wxWidgets` PortGroup.

 But I do imagine that there will be still be some PortGroups that will
 require blacklisting OSes, `cxx11` comes to mind as one (not 100% real)
 potential example. If we did not have this sophisticated machinery to
 allow building ports with C++11 on < 10.9, we would specify in the `cxx11`
 PortGroup that those ports cannot be built on `{darwin < 13}`. Now imagine
 a port that needs C++11 and cannot be built on 10.13. My approach would be
 to only specify
 {{{
 platforms {darwin < 17}
 }}}
 or
 {{{
 platforms-blacklist {darwin >= 17}
 }}}
 in the port itself, and leave blacklisting of `{darwin < 13}` to the
 PortGroup.

 I still believe that blacklisting is easier to implement and easier to
 understand than if you specify `{darwin < 17}` in the port and `{darwin >=
 13}` in the PortGroup if that should mean only darwin 13 up to 16.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:36>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by janstary):

 I agree it is useful to be able to express some global restriction,
 such as "you need at least _this_ version of darwin to build this".

 But the proposed whitelisting and blacklisting
 sounds like the opposite of keeping it simple.

 The default should be _empty_ . If the port does not specify "platforms"
 (i.e. the Portfile does not even use the platforms keyword) it should mean
 the port has no requirements about the platform it is being built on.
 Most ports should be like that.

 The ports which do need a specfic platform would then say `darwin 8` or
 `darwin >= 10` or `darwin < 7`.
 Does anyone know about a particular port that needs to express something
 more complex
 than the simple inequalities?

 The distinction between `darwin` and `macosx` is not realistic.
 Most ports say `darwin`, and imho only do so because the `platform` field
 is required (and ignored, LOL).
 Currently, 155 ports include `macosx` among their platforms; some of those
 have `darwin macosx`.
 Does that mean all the other ports do specifically _not_ require the Apple
 Frameworks? No it doesn't.

 This is what the Guide says about platforms now, confusingly:

 > A list of the platforms on which the port has been tested. Required, but
 not interpreted in any way by the software at this time; it is purely
 informational for users. Possible values: darwin (= macosx or puredarwin),
 macosx, puredarwin, freebsd, linux, sunos, netbsd. In general, it can just
 be set to darwin. (puredarwin is an OS based on Apple's open-source Darwin
 releases without any of Apple's proprietary bits.) See also os.platform.

 So people have been putting in `darwin`, or `macosx` which is _the_same_,
 or `puredarwin` which is also the same but does not exist.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:37>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by janstary):

 In fact, the specification should express what _doesn't_ work,
 the default being that the ports works, everywhere. For example, a port
 saying

 {{{
 broken darwin < 7 # Does not have strsep (or whatever)
 }}}

 would then stop building immediately on `darwin < 7`,
 because we know it does not build on this platform.

 I believe it is simpler and better than enumerating the working cases,
 which should be the vast majority, and the default.

 For comparison, OpenBSD has a BROKEN field for that.
 For example in `audio/xmms2/Makefile`:

 {{{
 BROKEN-sparc64 = waf build goes into an infinite loop
 }}}

 "We don't build here, and this is why."
 Isn't that the purpose of this proposal as well?

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:38>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by raimue):

 Regarding `darwin` vs. `macosx`: the keyword is "require". Most of the
 other ports will also build without Apple Frameworks, but will use them if
 available. Applications with a native GUI will choose `macosx`, as they
 cannot work without Apple Frameworks.

 As I see it, the guide is correct. Maybe it is not properly phrased, but
 `darwin` means any of `macosx` or `puredarwin` and these are not the same.
 They are also not handled the same in MacPorts base, which has the notion
 of `macosx` and `puredarwin` each being a subplatform of `darwin`. See
 `${os.subplatform}`.

 I agree that the specification is to exclude platforms. However, we always
 list the working cases. We also have `supported_archs` and not
 `broken_archs`.

 I do not think we need a way to express the reason why a port is broken. A
 comment in the Portfile should suffice. If someone encounters an
 unsupported platform and want to look into it, they will find the comment
 anyway.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:39>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by mojca):

 I'm not aware of any case of one PortGroup specifying `supported_archs
 i386 x86_64` and another one specifying `supported_archs ppc i386` which
 would mean that the port would only support `i386`. This variable needs
 much less intervention in general, just occasionally specifying that the
 port could not be built 64-bit.

 @janstary: there's no need to do any whitelisting. For me it's enough to
 keep just blacklisting or specifying "broken" state in which case my
 proposal is basically equivalent to yours, just using a different keyword
 (blacklist instead of broken). I don't care which keyword exactly is used,
 but it's nice if it's clear that
 {{{
 whatever-keywoard {darwin >= 13}
 }}}
 doesn't mean that the port will unconditionally build on any given 10.9 or
 above since another expression in a PortGroup could additionally declare a
 broken support for another OS version.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:40>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.7.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------
Changes (by mojca):

 * milestone:  MacPorts 2.6.0 => MacPorts 2.7.0


--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:41>
MacPorts <https://www.macports.org/>
Ports system for macOS
Reply | Threaded
Open this post in threaded view
|

Re: [MacPorts] #15712: Add versions to platforms

MacPorts
In reply to this post by MacPorts
#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.7.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by janstary):

 I like "broken" more than "blacklist" because "blacklist" seems to imply
 we intentionally don't want it, as opposed to "broken".

 At any rate, we should enumerate the bad, not the good;
 it should be understood that the port just works if it does not say
 anything.

--
Ticket URL: <https://trac.macports.org/ticket/15712#comment:42>
MacPorts <https://www.macports.org/>
Ports system for macOS