platforms

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

platforms

Jan Stary
The 'platforms' field of a Portfile is currently
both _required_ and _ignored_. By the Guide,

        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.

Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".

I propose that the 'platforms' field be no longer required
if it is ignored, and if it stays, let it be a free form text,
as opposed to a predefined definitive list of all unixes.

Better yet, drop it altogether. The fact that I tested on Solaris
or Debian means nothing regarding the MP port. I have also tested
it on darwin of course, but that goes without saying.

(What would be kinda useful is if it pointed to the actual _ports_
on the other systems - often there are things we can learn, as they
battle a lot of the same GNUisms etc. For example, the patch for opus
https://github.com/macports/macports-ports/pull/1217 is basically
the OpenBSD patch for opus. So if opus 'platforms' pointed to
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
it would be usefull. Unlike now.)

        Jan

Reply | Threaded
Open this post in threaded view
|

Re: platforms

Mojca Miklavec
On 24 March 2018 at 13:54, Jan Starý wrote:
> The 'platforms' field of a Portfile is currently
> both _required_ and _ignored_. By the Guide,
>
>         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.

I don't know anything about this, but it's possible that this could be
interpreted already, or maybe soon in the future.

> Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".

Personally I don't see any reason for not allowing "openbsd" (other
than the fact that only two ports will have that keyword, so it will
probably be useless at the end).

> I propose that the 'platforms' field be no longer required
> if it is ignored, and if it stays, let it be a free form text,
> as opposed to a predefined definitive list of all unixes.

We'll need it to specify which darwin versions are supported.

We currently have this ticket high on our priority list:
    https://trac.macports.org/ticket/15712

> Better yet, drop it altogether. The fact that I tested on Solaris
> or Debian means nothing regarding the MP port. I have also tested
> it on darwin of course, but that goes without saying.
>
> (What would be kinda useful is if it pointed to the actual _ports_
> on the other systems - often there are things we can learn, as they
> battle a lot of the same GNUisms etc. For example, the patch for opus
> https://github.com/macports/macports-ports/pull/1217 is basically
> the OpenBSD patch for opus. So if opus 'platforms' pointed to
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
> it would be usefull. Unlike now.)

You could (should?) provide such pointers in comments.
I always include sources of patches (or links to upstream tickets) if
I get them elsewhere, either in Portfile or in the patch itself.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: platforms

Ryan Schmidt-24

On Mar 24, 2018, at 08:14, Mojca Miklavec wrote:

>> I propose that the 'platforms' field be no longer required
>> if it is ignored, and if it stays, let it be a free form text,
>> as opposed to a predefined definitive list of all unixes.
>
> We'll need it to specify which darwin versions are supported.
>
> We currently have this ticket high on our priority list:
>    https://trac.macports.org/ticket/15712

Sure, it is one suggestion for how we could implement that feature, but it could be done in other ways.

Reply | Threaded
Open this post in threaded view
|

Re: platforms

Jan Stary
In reply to this post by Mojca Miklavec
On Mar 24 14:14:37, [hidden email] wrote:

> On 24 March 2018 at 13:54, Jan Starý wrote:
> > The 'platforms' field of a Portfile is currently
> > both _required_ and _ignored_. By the Guide,
> >
> >         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.
>
> I don't know anything about this, but it's possible that this could be
> interpreted already, or maybe soon in the future.

Does anybody know if it is interpretd then? Guide says no.

> > Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".
>
> Personally I don't see any reason for not allowing "openbsd" (other
> than the fact that only two ports will have that keyword, so it will
> probably be useless at the end).

It _is_ completely useless now, whatever you put there.

> > I propose that the 'platforms' field be no longer required
> > if it is ignored, and if it stays, let it be a free form text,
> > as opposed to a predefined definitive list of all unixes.
>
> We'll need it to specify which darwin versions are supported.

That would totaly change the meaning,
requiring a change of that filed for each and every port.
In fact, making a lot of current content illegal.

> We currently have this ticket high on our priority list:
>     https://trac.macports.org/ticket/15712

That's ten years old, and "there's no code written yet"
as of 13 days ago.

        Jan

> > Better yet, drop it altogether. The fact that I tested on Solaris
> > or Debian means nothing regarding the MP port. I have also tested
> > it on darwin of course, but that goes without saying.
> >
> > (What would be kinda useful is if it pointed to the actual _ports_
> > on the other systems - often there are things we can learn, as they
> > battle a lot of the same GNUisms etc. For example, the patch for opus
> > https://github.com/macports/macports-ports/pull/1217 is basically
> > the OpenBSD patch for opus. So if opus 'platforms' pointed to
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
> > it would be usefull. Unlike now.)
>
> You could (should?) provide such pointers in comments.
> I always include sources of patches (or links to upstream tickets) if
> I get them elsewhere, either in Portfile or in the patch itself.
>
> Mojca
Reply | Threaded
Open this post in threaded view
|

Re: platforms

Mojca Miklavec-2
On 25 March 2018 at 08:49, Jan Stary  wrote:
> On Mar 24 14:14:37, [hidden email] wrote:
>>
>> We currently have this ticket high on our priority list:
>>     https://trac.macports.org/ticket/15712
>
> That's ten years old, and "there's no code written yet"
> as of 13 days ago.

https://github.com/macports/macports-base/pull/68

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: platforms

Ryan Schmidt-24
In reply to this post by Jan Stary

On Mar 25, 2018, at 01:49, Jan Stary wrote:

> On Mar 24 14:14:37, Mojca wrote:
>> On 24 March 2018 at 13:54, Jan Starý wrote:
>>> The 'platforms' field of a Portfile is currently
>>> both _required_ and _ignored_. By the Guide,
>>>
>>>        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.
>>
>> I don't know anything about this, but it's possible that this could be
>> interpreted already, or maybe soon in the future.
>
> Does anybody know if it is interpretd then? Guide says no.

As far as I know, the platforms variable is not currently used.


>>> Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".
>>
>> Personally I don't see any reason for not allowing "openbsd" (other
>> than the fact that only two ports will have that keyword, so it will
>> probably be useless at the end).
>
> It _is_ completely useless now, whatever you put there.
>
>>> I propose that the 'platforms' field be no longer required
>>> if it is ignored, and if it stays, let it be a free form text,
>>> as opposed to a predefined definitive list of all unixes.
>>
>> We'll need it to specify which darwin versions are supported.
>
> That would totaly change the meaning,
> requiring a change of that filed for each and every port.
> In fact, making a lot of current content illegal.

Obviously if we go forward with the plan of reusing the platforms variable as a way to signify which versions of OS are acceptable, it will be done in such a way that the values ports are currently using for that variable are not considered illegal.


>> We currently have this ticket high on our priority list:
>>    https://trac.macports.org/ticket/15712
>
> That's ten years old, and "there's no code written yet"
> as of 13 days ago.

We are aware. It is a feature we have wanted for a long time, and it was recently decided that we should perhaps finally try to do something about it.


Reply | Threaded
Open this post in threaded view
|

Re: platforms

Rainer Müller-4
In reply to this post by Jan Stary
On 2018-03-24 13:54, Jan Starý wrote:

> The 'platforms' field of a Portfile is currently
> both _required_ and _ignored_. By the Guide,
>
> 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 user
> Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".
> I propose that the 'platforms' field be no longer required
> if it is ignored, and if it stays, let it be a free form text,
> as opposed to a predefined definitive list of all unixes.

I see the list of possible values in the guide as examples and
non-exhaustive. The wording could be better, though.

> Better yet, drop it altogether. The fact that I tested on Solaris
> or Debian means nothing regarding the MP port. I have also tested
> it on darwin of course, but that goes without saying.

As the guide says, it is "informational" at the moment. In the past,
more people were using MacPorts on FreeBSD, therefore they added their
test results to the port.

I agree it could be optional for the common case of "platforms darwin"
without any specific requirements on the version.

> (What would be kinda useful is if it pointed to the actual _ports_
> on the other systems - often there are things we can learn, as they
> battle a lot of the same GNUisms etc. For example, the patch for opus
> https://github.com/macports/macports-ports/pull/1217 is basically
> the OpenBSD patch for opus. So if opus 'platforms' pointed to
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
> it would be usefull. Unlike now.)

If a specific patch was taken from another distribution, information
should be right in the patch file. Some ports are already using
"Upstream:" or "Upstream-Status:" header lines in the patches. There is
no formal format for MacPorts, but it was loosely adopted from
OpenEmbedded [1].

I do not want to keep a list of all other package managers providing
libopus. There is already repology for this [2].

Rainer

[1]
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status
[2] https://repology.org/metapackage/opus/versions