On Mar 27, 2022, at 13:06, Richard L. Hamilton wrote:
>
> (although I think Apple provides the servers)
Apple provided the servers from late 2006 [1] (when our first home OpenDarwin
closed its doors) until late 2016 [2] (when Apple's macOS forge service shut
down). Since then, we have used
MacPorts is by nature not just one thing. There's the "port" command, related
commands, the structure of Portfiles; there's the servers that deliver up both
pre-built executables AND whether for lack of capacity to pre-build or because
certain ports need to be locally built, may also deliver
That's what I said and anyway I repeat for the nth time
to people that doesn't want to know it: it's YOUR stuff,
YOU should know what it is, I'm not here to tell you what
to do you with it, this just a friendly reminder to decide...
Il dom 27 mar 2022, 01:42 Ryan Schmidt ha scritto:
> On Mar
On Mar 26, 2022, at 00:48, Michele Venturi wrote:
> As usual this project too is a mess because everyone has a different idea of
> what it is,has been and will be.
If you have constructive criticism for changes that should be made, feel free
to start discussions about them. Otherwise you may
As usual this project too is a mess because everyone has a different idea
of what it is,has been and will be.
Il gio 24 mar 2022, 02:55 Ryan Schmidt ha scritto:
> On Mar 23, 2022, at 08:48, Michele Venturi wrote:
>
> > If MacPorts is not a package manager we need one,
> > I'd say HomeBrew could
On Mar 23, 2022, at 08:48, Michele Venturi wrote:
> If MacPorts is not a package manager we need one,
> I'd say HomeBrew could be the right tool for the job.
I'm not sure what these remarks are in regards to, but MacPorts was started in
2002 a ports collection [1] based conceptually on FreeBSD
MacPorts is, by a long margin, the best package manager for macOS and Mac OS X
before it.
Homebrew is more like a cult than a package manager, and it has always been
redundant and inferior to MacPorts. It is inferior due to the way it botches
permissions, and specifically the way it creates
My problem is that "MacPorts is not (just) 'a simple package manager'. "
Il mer 23 mar 2022, 21:11 Dave Horsfall ha scritto:
> On Wed, 23 Mar 2022, Michele Venturi wrote:
>
> > If MacPorts is not a package manager we need one,I'd say HomeBrew could
> > be the right tool for the job.
>
> I find
On Wed, 23 Mar 2022, Michele Venturi wrote:
> If MacPorts is not a package manager we need one,I'd say HomeBrew could
> be the right tool for the job.
I find that MacPorts is a most excellent package manager; what exactly is
your problem?
-- Dave
If MacPorts is not a package manager we need one,
I'd say HomeBrew could be the right tool for the job.
Il lun 14 mar 2022, 18:02 Ryan Schmidt ha scritto:
> On Mar 14, 2022, at 10:40, James Secan wrote:
>
> > It is a macOS alias. I use soft links a lot, but only for items that
> I’m accessing
On Mar 14, 2022, at 10:40, James Secan wrote:
> It is a macOS alias. I use soft links a lot, but only for items that I’m
> accessing when working in a Unix shell.
MacPorts should be able to use your Xcode wherever it is, provided that
`xcode-select -p` shows its path or the path of a symlink
It is a macOS alias. I use soft links a lot, but only for items that I’m
accessing when working in a Unix shell.
Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109
> On Mar 13, 2022, at 1:46 PM, xpl...@wak.co.nz wrote:
>
> I forgot to ad, the reason, at a unix level, the Finder alias just
I forgot to ad, the reason, at a unix level, the Finder alias just just another
boring file, not the intended alias. This is similar to how Windows shortcuts
look on Macs, where they come through as a .lnk file that the Mac doesn’t
understand.
--
Richard Smith
xpl...@wak.co.nz
> On
Is it a Mac Alias, or a unix ln ? (i.e. the former is created with a
drag-n-drop of the App holding down the Command & Option keys, while the former
is created with the command ln -s /path/to/app lnfile, and that is a lowercase
L, not an uppercase i). MacPorts will work better with the latter
I do have the full Xcode package installed (8.2.1) on the El Capitan system,
although I have it as an alias in the Applications directory (on a smallish
SSD) linking to the actual Xcode files on an internal HD because it requires a
lot of disk real estate and I never use Xcode. Would that
On Mar 12, 2022, at 21:57, Richard L. Hamilton wrote:
> Is there a way one can see by examining Portfiles (ideally something that
> could be scanned for with e.g. a perl script), or preferably, with some
> "port" command, which ports require command line tools vs Xcode vs neither
> (albeit
Is there a way one can see by examining Portfiles (ideally something that could
be scanned for with e.g. a perl script), or preferably, with some "port"
command, which ports require command line tools vs Xcode vs neither (albeit
perhaps needing something to get a compiler port installed)?
> On
On Mar 11, 2022, at 02:02, Michele Venturi wrote:
> What is wrong is that a simple package manager
> requires an entire multigigabyte professional IDE;
> I have even taken the time to talk to them about it
> and file a bug about it,but they clearly don't care...
> It's surely not a new issue,it's
On Mar 10, 2022, at 18:40, James Secan wrote:
> In working my way through my recent “phantom ports” issue I ran the command
> “port diagnose” and was more than a bit surprised by the output line:
>
> Error: currently installed version of Xcode, none, is not supported by
> MacPorts.
>
>
I truly appreciate everyone who maintains things for MP - couldn’t live without
this stuff. My initial query was just trying to understand whether ‘port
diagnose’ was telling me something I should be concerned about. I think the
answer was ‘no’.
The message could be improved for that case,
I truly appreciate everyone who maintains things for MP - couldn’t live without
this stuff. My initial query was just trying to understand whether ‘port
diagnose’ was telling me something I should be concerned about. I think the
answer was ‘no’.
Jim
3222 NE 89th St
Seattle, WA 98115
(206)
On Fri, 11 Mar 2022, Chris Jones wrote:
> MacPorts is not (just) 'a simple package manager'. Yes, it performs this
> function, but first and foremost (and long before we even had binary
> tarballs to distribute as a 'package mnager') it is a system for
> building packages and their
On 11/03/2022 8:02 am, Michele Venturi wrote:
What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that
What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...
Il ven 11 mar 2022, 01:40 James
24 matches
Mail list logo
