> On Jun 22, 2020, at 8:32 PM, Ryan Schmidt wrote:
>
> I can't corroborate that claim, but of course we are interested in reducing
> bloat in MacPorts and welcome any suggestions or improvements toward that end.
I’m surprised — that has always been near point #1 on every homebrew vs.
On Mon, 22 Jun 2020 at 21:34, Daniel J. Luke wrote:
>
> We'd just need to either revbump everything that needs a rebuild when a new
> minor perl version comes out (all the p5- ports to start)
I would say that we happily accept a pull request that "just bumps"
all dependents of perl5[.x].
Then
On Jun 22, 2020, at 23:21, Nils Breunese wrote:
> Jason Liu wrote:
>
>> Would it be possible to sort of split the difference? i.e. not _just_ have
>> one single perl5 port and get rid of all the individual point releases, but
>> rather to add perl5 as a sort of "metapackage" that is
Now that Apple has announced that Macs will have ARM processors [1], what is
the proper value for ${os.arch} on such systems?
MacPorts base currently knows two values of ${os.arch}: "powerpc" is used on
all 32-bit and 64-bit PowerPC systems while "i386" is used on all 32-bit and
64-bit Intel
Jason Liu wrote:
> Would it be possible to sort of split the difference? i.e. not _just_ have
> one single perl5 port and get rid of all the individual point releases, but
> rather to add perl5 as a sort of "metapackage" that is essentially the same
> as perl5.30. I guess metapackage isn't
On Jun 22, 2020, at 23:00, Jason Liu wrote:
> On Mon, Jun 22, 2020 at 11:21 PM Ryan Schmidt wrote:
>
>> I've just realized this discussion has been to the old list address from
>> macosforge. Please always use the new list addresses at lists.macports.org.
>>
>>
>> On Jun 22, 2020, at
Would it be possible to sort of split the difference? i.e. not _just_ have
one single perl5 port and get rid of all the individual point releases, but
rather to add perl5 as a sort of "metapackage" that is essentially the same
as perl5.30. I guess metapackage isn't the right word, either. In
On Jun 22, 2020, at 22:26, Jason Liu wrote:
>> We should just have one perl5 port that tracks the current release. We'd
>> just need to either revbump everything that needs a rebuild when a new minor
>> perl version comes out (all the p5- ports to start) OR some enhancement to
>> base to
On 2020-06-22, at 1:12 PM, Dr M J Carter wrote:
> Rats: you beat me to it. I'll restrict myself to reminiscing about
> dylibs having allegedly been invented (by Sun?) out of embarrassment,
> on finding hello.c was bloated, to 3MBytes iirc, by printf() dragging
> in half the known universe at
On Jun 22, 2020, at 09:59, Ken Cunningham wrote:
> Perhaps unavoidable in some cases, but if you look around the web, this is in
> fact the #1 complaint about MacPorts: bloat.
I can't corroborate that claim, but of course we are interested in reducing
bloat in MacPorts and welcome any
>
> We should just have one perl5 port that tracks the current release. We'd
> just need to either revbump everything that needs a rebuild when a new
> minor perl version comes out (all the p5- ports to start) OR some
> enhancement to base to make it so the revbump is unnecessary.
>
> It might
I just pushed some changes to base/master and dports/master to better support
macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.
Some common issues to be aware of:
1) libtool required an update for the version bump. This means many projects
might need an autoreconf to
On Mon, Jun 22, 2020 at 03:34:39PM -0400, Daniel J. Luke wrote:
> On Jun 22, 2020, at 10:59 AM, Ken Cunningham
> wrote:
> > Perhaps unavoidable in some cases, but if you look around the web, this is
> > in fact the #1 complaint about MacPorts: bloat.
>
> It's somewhat ironic given the current
On Jun 22, 2020, at 10:59 AM, Ken Cunningham
wrote:
> Perhaps unavoidable in some cases, but if you look around the web, this is in
> fact the #1 complaint about MacPorts: bloat.
It's somewhat ironic given the current trend of everything being containerized
(and bringing in all of their
Agreed.
I’ve chosen to have my main build machine run perl5.30, but that causes ports
like help2man to try to reinstall perl5.28.
On my FreeBSD machines you set the Perl branch in /etc/make.conf, and all the
Makefiles respect that setting.
Marius
--
Marius Schamschula
> On Jun 22, 2020,
A simple used-to-be-quick build of "curl" now requires two different perls
installed.
Perhaps unavoidable in some cases, but if you look around the web, this is in
fact the #1 complaint about MacPorts: bloat.
It might be an idea for the admins to "set" the perl version all ports will use
16 matches
Mail list logo
