Re: [122715] trunk/dports/sysutils/parallel/Portfile
On 7/27/14, 11:49 AM, Ryan Schmidt wrote: On Jul 27, 2014, at 9:56 AM, khindenb...@macports.org wrote: Revision 122715 Author khindenb...@macports.org Date 2014-07-27 07:56:16 -0700 (Sun, 27 Jul 2014) Log Message parallel: remove conflicts moreutils Modified Paths • trunk/dports/sysutils/parallel/Portfile No reason to increase the revision, by the way, unless you're changing the files the port installs. Ok, thanks for the information. I'll try to remember this. Kurt ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [122715] trunk/dports/sysutils/parallel/Portfile
> On Jul 27, 2014, at 9:56 AM, khindenb...@macports.org wrote: > > Revision > 122715 > Author > khindenb...@macports.org > Date > 2014-07-27 07:56:16 -0700 (Sun, 27 Jul 2014) > Log Message > > parallel: remove conflicts moreutils > Modified Paths > > • trunk/dports/sysutils/parallel/Portfile No reason to increase the revision, by the way, unless you're changing the files the port installs. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Database bindings
> On Jul 27, 2014, at 8:54 AM, Craig Treleaven wrote: > > Hi: > > My myth* ports need Perl, Python and Php bindings to the database. Up to now, > I've used mysql5 for the database and the relevant ports for the bindings > defaulted to the same--life was good! But all good things change and we want > to phase out mysql5. Now...life is a little less good. > > The 'binding' ports are: > > py27-mysql > variants [+]mariadb55, mysql4, mysql51, mysql55, mysql56, percona55 > > p5.16-dbd-mysql > variants mariadb, mysql4, [+]mysql5, mysql51, mysql55, percona > > php54-mysql > variants mariadb, mysql4, mysql5, mysql51, mysql55, mysql56, [+]mysqlnd, > percona > > Issues: > py-mysql and p-dbd-mysql default to different databases. > > There are inconsistencies in the naming of the maria and percona variants: > mariadb55 v. mariadb and percona55 v. percona. Agreed, the names should be made consistent. The assumption was that there would be separate versioned ports for mariadb an percona, hence the change to versioned suffixes for these variants in some ports. The variant names should probably be made consistent. > p5-dbd-mysql doesn't offer a mysql56 variant. Missing variants should be added. > Now that we have maria10.0 and maria10.1 ports, should we not have matching > variants -- maria, maria10.0 and maria10.1? I'd like to avoid giving users the impression that "mariadb" would be the correct variant to use for mariadb support. "mariadb55" makes it clearer that it's an older version. > From my point of view, it would be ideal if these bindings were subports > instead of variants so that I can ensure that users get the right bindings. > Either that or MacPorts needs to pick one database and version as THE ONE. I > know this has been debated but (to my knowledge) not resolved. They shouldn't be subports; they should remain variants. There should be no problem if the bindings use a different library than the server. e.g. php54-mysql built using mysql55 should have no problem talking to a mariadb server since they all speak the same mysql protocol. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Database bindings
Hi: My myth* ports need Perl, Python and Php bindings to the database. Up to now, I've used mysql5 for the database and the relevant ports for the bindings defaulted to the same--life was good! But all good things change and we want to phase out mysql5. Now...life is a little less good. The 'binding' ports are: py27-mysql variants [+]mariadb55, mysql4, mysql51, mysql55, mysql56, percona55 p5.16-dbd-mysql variants mariadb, mysql4, [+]mysql5, mysql51, mysql55, percona php54-mysql variants mariadb, mysql4, mysql5, mysql51, mysql55, mysql56, [+]mysqlnd, percona Issues: py-mysql and p-dbd-mysql default to different databases. There are inconsistencies in the naming of the maria and percona variants: mariadb55 v. mariadb and percona55 v. percona. p5-dbd-mysql doesn't offer a mysql56 variant. Now that we have maria10.0 and maria10.1 ports, should we not have matching variants -- maria, maria10.0 and maria10.1? From my point of view, it would be ideal if these bindings were subports instead of variants so that I can ensure that users get the right bindings. Either that or MacPorts needs to pick one database and version as THE ONE. I know this has been debated but (to my knowledge) not resolved. Thoughts? Craig PS I think Ruby has similar issues; maybe others. Thank God I don't have any more bindings to mess with. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: perl5.20
> On Jul 27, 2014, at 7:50 AM, Mojca Miklavec wrote:
>
> On Sun, Jul 27, 2014 at 2:20 PM, Ryan Schmidt wrote:
>>> On Jul 27, 2014, at 3:59 AM, Mojca Miklavec wrote:
>>>
>>> On Thu, Jul 24, 2014 at 11:20 AM, Joshua Root wrote:
On 2014-7-24 01:20 , Mojca Miklavec wrote:
> One slightly easier step-by-step approach could be the following
>
> 1.) Replace
> perl5.branches 5.14 5.16 5.18
> in all perl modules with
> perl5.branches_blacklist 5.8 5.10 5.12
> or to remove branche_blacklist altogether if the module builds with
> all perl versions. When that blacklist isn't present (or empty) simply
> make the module work with all known perl versions (defined in the
> PortGroup).
There's no need for an additional option and code for blacklisting. If
you want modules to opt out of perl versions rather than opting in, set
a default for perl5.branches in the portgroup, containing all the
versions. Then use perl5.branches-delete in portfiles to remove the perl
versions that they don't work with.
>>>
>>> Like this?
>>>
>>>
>>> Index: _resources/port1.0/group/perl5-1.0.tcl
>>> ===
>>> --- _resources/port1.0/group/perl5-1.0.tcl(revision 122703)
>>> +++ _resources/port1.0/group/perl5-1.0.tcl(working copy)
>>> @@ -39,6 +39,7 @@
>>> # perl5.default_branch: the branch used when you request p5-foo
>>> options perl5.default_branch perl5.branches
>>> default perl5.default_branch {[perl5_get_default_branch]}
>>> +perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>>>
>>> proc perl5_get_default_branch {} {
>>>global prefix perl5.branches
>>> Index: perl/p5-wx/Portfile
>>> ===
>>> --- perl/p5-wx/Portfile(revision 122703)
>>> +++ perl/p5-wx/Portfile(working copy)
>>> @@ -9,8 +9,8 @@
>>> # but earlier perl versions provide too old ParseXL versions and thus
>>> cannot be built
>>> # So 5.14 is the lowest version of Perl that used to work until recently
>>> # but is now broken as well: https://trac.macports.org/ticket/43157
>>> -#perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18
>>> -perl5.branches 5.16 5.18 5.20
>>> +perl5.branches-delete \
>>> +5.8 5.10 5.12 5.14
>>> perl5.setup Wx 0.9923
>>> revision1
>>>
>>>
>>> Is it perfectly safe if I simply add
>>> perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>>> to the PortGroup and then start removing "perl5.branches" from
>>> individual perl ports? If so, I would add that line, but I need a
>>> confirmation from more experienced users.
>>
>> And why again is this preferable to listing perl5.branches in each p5 port
>> like we have now?
>>
>> The reason why it's in each p5 port now is that it is each p5 port's
>> responsibility to know and declare which perl versions it's compatible with.
>> The perl5 portgroup can't know that.
>
> The advantage would be that adding "5.20" to the PortGroup would
> enable p5.20-foo for all modules. But yes, we would need to manually
> rebuild all the perl modules on the buildbots. This means collecting a
> list of modules and passing it to each buildbot once (a better option
> would be to pass a directory to the buildbot and ask the buildbot to
> build all modules).
>
> The incompatible modules could then blacklist their incompatibility
> with the latest perl version when needed.
>
> Currently the problem is that lots of modules are perfectly
> compatible, but one can only add 5.20 once all the dependencies add
> 5.20.
>
> In other cases the modules are again perfectly compatible with perl
> version X, but one of the dependencies is broken. For example
> p5.10-parse-cpan-meta (https://trac.macports.org/ticket/42146) or
> p5.14-extutils-xspp (https://trac.macports.org/ticket/43157) make *a
> lot* of p5.10-foo and p5.14-foo modules broken. Not because modules
> themselves are incompatible, but because we have a broken perl
> installation. It's not clear to me whether modules should then list
> incompatibility with that perl version or not.
>
> I cannot imagine anyone actually checking if all the 2000 modules
> (cca. 1000 modules for perl 5.18 and 5.20) work properly and are
> compatible with Perl 5.18/5.20. So if we ever want to reach the point
> porting all the modules to Perl 5.20, this will have to be done with a
> script.
>
> Now imagine a module where the maintainer actually checked and
> confirmed that a particular module doesn't work with 5.20 and thus
> left it out on purpose. How would such a script distinguish that
> deliberate decision to leave 5.20 out and 999 other ports where the
> lack of 5.20 is just because nobody cared enough to add support for
> 5.20 to either that port or to one of the zillion of its dependencies?
That's a good point. I've seen some ports where a comment has been added
explaining why a perl version is not available, but that's not
Re: perl5.20
On Sun, Jul 27, 2014 at 2:20 PM, Ryan Schmidt wrote:
>> On Jul 27, 2014, at 3:59 AM, Mojca Miklavec wrote:
>>
>> On Thu, Jul 24, 2014 at 11:20 AM, Joshua Root wrote:
>>> On 2014-7-24 01:20 , Mojca Miklavec wrote:
One slightly easier step-by-step approach could be the following
1.) Replace
perl5.branches 5.14 5.16 5.18
in all perl modules with
perl5.branches_blacklist 5.8 5.10 5.12
or to remove branche_blacklist altogether if the module builds with
all perl versions. When that blacklist isn't present (or empty) simply
make the module work with all known perl versions (defined in the
PortGroup).
>>>
>>> There's no need for an additional option and code for blacklisting. If
>>> you want modules to opt out of perl versions rather than opting in, set
>>> a default for perl5.branches in the portgroup, containing all the
>>> versions. Then use perl5.branches-delete in portfiles to remove the perl
>>> versions that they don't work with.
>>
>> Like this?
>>
>>
>> Index: _resources/port1.0/group/perl5-1.0.tcl
>> ===
>> --- _resources/port1.0/group/perl5-1.0.tcl(revision 122703)
>> +++ _resources/port1.0/group/perl5-1.0.tcl(working copy)
>> @@ -39,6 +39,7 @@
>> # perl5.default_branch: the branch used when you request p5-foo
>> options perl5.default_branch perl5.branches
>> default perl5.default_branch {[perl5_get_default_branch]}
>> +perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>>
>> proc perl5_get_default_branch {} {
>> global prefix perl5.branches
>> Index: perl/p5-wx/Portfile
>> ===
>> --- perl/p5-wx/Portfile(revision 122703)
>> +++ perl/p5-wx/Portfile(working copy)
>> @@ -9,8 +9,8 @@
>> # but earlier perl versions provide too old ParseXL versions and thus
>> cannot be built
>> # So 5.14 is the lowest version of Perl that used to work until recently
>> # but is now broken as well: https://trac.macports.org/ticket/43157
>> -#perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18
>> -perl5.branches 5.16 5.18 5.20
>> +perl5.branches-delete \
>> +5.8 5.10 5.12 5.14
>> perl5.setup Wx 0.9923
>> revision1
>>
>>
>> Is it perfectly safe if I simply add
>>perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>> to the PortGroup and then start removing "perl5.branches" from
>> individual perl ports? If so, I would add that line, but I need a
>> confirmation from more experienced users.
>
> And why again is this preferable to listing perl5.branches in each p5 port
> like we have now?
>
> The reason why it's in each p5 port now is that it is each p5 port's
> responsibility to know and declare which perl versions it's compatible with.
> The perl5 portgroup can't know that.
The advantage would be that adding "5.20" to the PortGroup would
enable p5.20-foo for all modules. But yes, we would need to manually
rebuild all the perl modules on the buildbots. This means collecting a
list of modules and passing it to each buildbot once (a better option
would be to pass a directory to the buildbot and ask the buildbot to
build all modules).
The incompatible modules could then blacklist their incompatibility
with the latest perl version when needed.
Currently the problem is that lots of modules are perfectly
compatible, but one can only add 5.20 once all the dependencies add
5.20.
In other cases the modules are again perfectly compatible with perl
version X, but one of the dependencies is broken. For example
p5.10-parse-cpan-meta (https://trac.macports.org/ticket/42146) or
p5.14-extutils-xspp (https://trac.macports.org/ticket/43157) make *a
lot* of p5.10-foo and p5.14-foo modules broken. Not because modules
themselves are incompatible, but because we have a broken perl
installation. It's not clear to me whether modules should then list
incompatibility with that perl version or not.
I cannot imagine anyone actually checking if all the 2000 modules
(cca. 1000 modules for perl 5.18 and 5.20) work properly and are
compatible with Perl 5.18/5.20. So if we ever want to reach the point
porting all the modules to Perl 5.20, this will have to be done with a
script.
Now imagine a module where the maintainer actually checked and
confirmed that a particular module doesn't work with 5.20 and thus
left it out on purpose. How would such a script distinguish that
deliberate decision to leave 5.20 out and 999 other ports where the
lack of 5.20 is just because nobody cared enough to add support for
5.20 to either that port or to one of the zillion of its dependencies?
I agree that explicitly listing a perl version is better in principle,
but I cannot imagine it working the way we would want it to work.
> Additionally, a port only gets indexed when that port is modified. So
> consider some future point in time where perl5.branches is only in the perl5
> portgroup and has been removed from all p5 port
Re: github portgroup release tarball url
> On Jul 26, 2014, at 3:19 PM, Joshua Root wrote:
>
> On 2014-7-27 05:54 , Ryan Schmidt wrote:
>> On Jul 25, 2014, at 6:41 PM, Jean-Philippe Ouellet
>> wrote:
>>
>>> Hello,
>>>
>>> In the github portgroup, the urls it uses to fetch releases are:
>>> ${github.homepage}/releases/download/${git.branch}
>>> and
>>> ${github.homepage}/tarball/${git.branch}
>>>
>>> which fetches a tarball that extracts to
>>> ${author}-${project}-${git_hash}/
>>> which we then need to fix in post-extract.
>>>
>>>
>>> The tarball for the release linked to from the github web interface is
>>> ${github.homepage}/archive/${version}.tar.gz
>>> which extracts to
>>> ${project}-${version}/
>>> which I think would be cleaner. (and is used in the majority of brew ports)
>>
>> This change has been suggested before:
>>
>> https://trac.macports.org/ticket/40518
>>
>> I was not aware of the benefit you mention, and that is indeed a helpful
>> change. However, there are also drawbacks I mentioned in the ticket. It
>> would come down to needing to define a new portgroup option for whether or
>> not to use the legacy tarball urls, editing each port using these tarballs
>> to set the value to yes, and remembering to remove that line when updating
>> each of those ports to the next version.
>
> The tarball URLs aren't actually legacy AFAICT, they're still a
> documented part of the github API:
>
>
>
> Both the tarball and archive URLs actually redirect somewhere else.
Ok. We could also handle it as just another valid value for the
github.tarball_from option. I'm just still not sure why github offers two URL
formats that serve more or less the same purpose, delivering the same contents
in slightly different packaging.
>>> I found this issue while wondering why I kept getting checksum
>>> mismatches in macports when it worked perfectly in homebrew.
>>
>> You shouldn't be getting checksum mismatches...
>
> You do if you try to use the same checksums in brew and macports.
I meant you shouldn't be getting checksum mismatches during the normal course
of using MacPorts (which would include not also using Homebrew). If checksum
mismatches are encountered, it should be reported as a bug.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: perl5.20
> On Jul 27, 2014, at 3:59 AM, Mojca Miklavec wrote:
>
> On Thu, Jul 24, 2014 at 11:20 AM, Joshua Root wrote:
>> On 2014-7-24 01:20 , Mojca Miklavec wrote:
>>> One slightly easier step-by-step approach could be the following
>>>
>>> 1.) Replace
>>>perl5.branches 5.14 5.16 5.18
>>> in all perl modules with
>>>perl5.branches_blacklist 5.8 5.10 5.12
>>> or to remove branche_blacklist altogether if the module builds with
>>> all perl versions. When that blacklist isn't present (or empty) simply
>>> make the module work with all known perl versions (defined in the
>>> PortGroup).
>>
>> There's no need for an additional option and code for blacklisting. If
>> you want modules to opt out of perl versions rather than opting in, set
>> a default for perl5.branches in the portgroup, containing all the
>> versions. Then use perl5.branches-delete in portfiles to remove the perl
>> versions that they don't work with.
>
> Like this?
>
>
> Index: _resources/port1.0/group/perl5-1.0.tcl
> ===
> --- _resources/port1.0/group/perl5-1.0.tcl(revision 122703)
> +++ _resources/port1.0/group/perl5-1.0.tcl(working copy)
> @@ -39,6 +39,7 @@
> # perl5.default_branch: the branch used when you request p5-foo
> options perl5.default_branch perl5.branches
> default perl5.default_branch {[perl5_get_default_branch]}
> +perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>
> proc perl5_get_default_branch {} {
> global prefix perl5.branches
> Index: perl/p5-wx/Portfile
> ===
> --- perl/p5-wx/Portfile(revision 122703)
> +++ perl/p5-wx/Portfile(working copy)
> @@ -9,8 +9,8 @@
> # but earlier perl versions provide too old ParseXL versions and thus
> cannot be built
> # So 5.14 is the lowest version of Perl that used to work until recently
> # but is now broken as well: https://trac.macports.org/ticket/43157
> -#perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18
> -perl5.branches 5.16 5.18 5.20
> +perl5.branches-delete \
> +5.8 5.10 5.12 5.14
> perl5.setup Wx 0.9923
> revision1
>
>
> Is it perfectly safe if I simply add
>perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
> to the PortGroup and then start removing "perl5.branches" from
> individual perl ports? If so, I would add that line, but I need a
> confirmation from more experienced users.
And why again is this preferable to listing perl5.branches in each p5 port like
we have now?
The reason why it's in each p5 port now is that it is each p5 port's
responsibility to know and declare which perl versions it's compatible with.
The perl5 portgroup can't know that.
Additionally, a port only gets indexed when that port is modified. So consider
some future point in time where perl5.branches is only in the perl5 portgroup
and has been removed from all p5 ports, and now you add 5.22 to perl5.branches
in the perl5 portgroup. None of the existing p5 ports will gain knowledge of
that change until they are themselves modified. So now we would be talking
about making any random edit to each p5 port just to get it reindexed. Why is
that preferable to just leaving the perl5.branches line in each p5 port and
updating it as needed, as we have now?
That's a rhetorical question. It's not, which is why we changed it 2 years ago
to move perl5.branches from the perl5 portgroup into each p5 port.
http://trac.macports.org/ticket/34784
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: perl5.20
On Thu, Jul 24, 2014 at 11:20 AM, Joshua Root wrote:
> On 2014-7-24 01:20 , Mojca Miklavec wrote:
>> One slightly easier step-by-step approach could be the following
>>
>> 1.) Replace
>> perl5.branches 5.14 5.16 5.18
>> in all perl modules with
>> perl5.branches_blacklist 5.8 5.10 5.12
>> or to remove branche_blacklist altogether if the module builds with
>> all perl versions. When that blacklist isn't present (or empty) simply
>> make the module work with all known perl versions (defined in the
>> PortGroup).
>
> There's no need for an additional option and code for blacklisting. If
> you want modules to opt out of perl versions rather than opting in, set
> a default for perl5.branches in the portgroup, containing all the
> versions. Then use perl5.branches-delete in portfiles to remove the perl
> versions that they don't work with.
Like this?
Index: _resources/port1.0/group/perl5-1.0.tcl
===
--- _resources/port1.0/group/perl5-1.0.tcl(revision 122703)
+++ _resources/port1.0/group/perl5-1.0.tcl(working copy)
@@ -39,6 +39,7 @@
# perl5.default_branch: the branch used when you request p5-foo
options perl5.default_branch perl5.branches
default perl5.default_branch {[perl5_get_default_branch]}
+perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
proc perl5_get_default_branch {} {
global prefix perl5.branches
Index: perl/p5-wx/Portfile
===
--- perl/p5-wx/Portfile(revision 122703)
+++ perl/p5-wx/Portfile(working copy)
@@ -9,8 +9,8 @@
# but earlier perl versions provide too old ParseXL versions and thus
cannot be built
# So 5.14 is the lowest version of Perl that used to work until recently
# but is now broken as well: https://trac.macports.org/ticket/43157
-#perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18
-perl5.branches 5.16 5.18 5.20
+perl5.branches-delete \
+5.8 5.10 5.12 5.14
perl5.setup Wx 0.9923
revision1
Is it perfectly safe if I simply add
perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
to the PortGroup and then start removing "perl5.branches" from
individual perl ports? If so, I would add that line, but I need a
confirmation from more experienced users.
> On another topic related to updating perl modules, how about we remove
> all the p5 ports that don't need to exist? If a module is not (directly
> or indirectly) (a) depending on something that is in MacPorts but not in
> CPAN, or (b) depended on by something that is in MacPorts but not in
> CPAN; it should really just be installed with CPAN.
I have mixed feelings about that. If nothing else people might install
modules with CPAN, then update MacPorts and their scripts might stop
working.
We certainly need to fix a lot of things related to Perl, but it's
basically impossible to figure out which modules could be removed. We
might end up removing one module just to discover that someone
submitted a ticket to request some other piece of software that
requires the deleted module.
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
