Sure, sure, I just took your email as a stimulus to express what I had in mind about the project. Hope I did not bother any of you too much… :). It’s always cool to investigate something and I think it’s interesting to know that Macports, actually works on Linux!
_
-. .´ |∞∞∞∞
', ; |∞∞∞∞∞∞
˜˜ |∞∞∞∞∞∞∞∞∞ RdB
,., |∞∞∞∞∞∞
.' '. |∞∞∞∞
-' `’
https://rdb.is
On 1 May 2020 at 04:55:14, Kenneth F. Cunningham
([email protected]) wrote:
You could be correct.
For some years, Portfile authours have been asked to always account for the
fact that MacPorts was designed to be cross-platform, and to take steps to make
sure the Portfiles remain so.
That's all the "platform darwin" stuff in all the Portfiles and in base.
I was just curious if MacPorts actually did work on Linux, and -- it turns out
-- it does, with minor surgery.
So we're not really "making" it cross-platform; it always has been.
I was just more seeing if it truly worked.
K
On 2020-04-30, at 7:07 PM, Ruben Di Battista wrote:
Can I express a thought about this? :) I hope I won’t result too naive.
I think the effort of making Macports cross-platform could be destined to
something else. On Linux there's a wide plethora of package managers that
fulfill basically all the needs Macports would fulfill. Just to take something
as an example:
* Pacman on Arch provides pre-compiled binaries plus the AUR repository of
packages that can be compiled at will (variants are missing, tho)
* Nix, that I think it's probably the most "correct" package manager currently
available over there.
* Spack, something like Nix, but optimized for HPC (so cross-compiling,
architecture optimization and so on).
but I'm surely missing other cool projects.
IMHO Macports should focus exclusively on macOS. As a contributor to Spack,
Macports (and EasyBuild in the past), I found the TCL based system very hard to
grasp w.r.t. Python-class based packages. That's probably because I'm more
proficient in Python, but I think it's undeniable that Python is an easier
language to pick and gradually learn, and with could also argue on the fact
that an Object-Oriented approach to package description is easier to maintain
(I don't know, I find it easier than the scripts we use in Macports).
IMHO Macports should focus into potentiating the major selling points it has,
again I pick something I have in mind myself:
* Native build of libraries and its dependencies
* Compatibility with old macOS versions
* Vast Linux and Unix selection of packages
and improve some aspects that could be improved:
* Abandon (not abruptly…) TCL for a more modern language, possibly more
mainstream, that could enlarge the audience of possible contributors for
packages
* Is the core written in C? I even don't know, but if it is, is it needed for
performance reasons?
* Improve compatibility and performances of "Linux-polarized" libraries (e.g.
Inkscape and GTK stuff)
* Provide pre-compiled binaries also for variants to speedup installation for
non-dev users
* Improve community engagement (e.g. switching mailing list to Discourse [it
ships mailing list mode if you prefer to communicate this way, but it would
improve indexing and searchability], IRC --> Matrix, and so on. Just
suggesting...)
Is there a Roadmap for the development of Macports? Is there somewhere where I
can see what was discussed and which direction Macports has been thought to
take? I would really like to participate, also as a way to learn something from
most of you that are way more skilled then me. I prefer Macports approach
w.r.t. Homebrew, and I'd like that people would be able to evaluate more fairly
the two solutions, maybe avoiding the difficult initial slope associated to TCL
and C-Core.
Tell me what you think, and sorry if I'm being too naive on some points. I'm a
fairly recent member and reader of the mailing list, I could have missed some
important discussions.
_
-. .´ |∞∞∞∞
', ; |∞∞∞∞∞∞
˜˜ |∞∞∞∞∞∞∞∞∞ RdB
,., |∞∞∞∞∞∞
.' '. |∞∞∞∞
-' `’
https://rdb.is
On 1 May 2020 at 03:37:28, Ken Cunningham ([email protected])
wrote:
I thought I would start up a short thread on progress with this --
MacPorts on Linux. We've long written the Portfiles with this in mind.
This was done on an Intel system, with the current Ubuntu 20.04. Ubuntu
19.10 can be installed in a VM in parallels, and no doubt in other VM
systems.
Some quick notes:
apt is the built-in package manager, similar to "port".
"sudo apt install" is the same as "sudo port install".
"apt info" is "port info"
"apt-file show" does something similar to "port contents", but the
software does not have to be installed.
After downloading the MacPorts source tarball, and prior to building
MacPorts, you must install the supporting software that comes already on
Macs that MacPorts expects to find.
These were installed as:
sudo apt install mtree-netbsd
sudo apt install tcl8.6
sudo apt install curl
sudo apt install sqlite3
sudo apt install gnustep
sudo apt install libcurl4-gnutls-dev
sudo apt install libsqlite3-dev
my system already had llvm-10 and clang-10 installed, and there was
already a symlink "port" linking /usr/bin/clang to the selected clang
binary, in this case clang-10.
Then build and install MacPorts as usual, into /opt/local
./configure && make && sudo make install
Add to your PATH as usual, but on Ubuntu, by editing ".bashrc", adding:
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
Adding that PATH to the sudo command is harder -- it doesn't pick it up
from the above ".bashrc". You have add it to the sudoers command with:
sudo visudo
and then add it to the secure_path
Defaults
secure_path="/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
There are some differences between Darwin and Ubuntu, and to work around
some of these that are not already compensated for by MacPorts base, I
did this:
edit macports.conf
sudo gedit /opt/local/etc/macports/macports.conf
and add:
buildmakejobs 2 # or a more appropriate
number for your processor count
default_compilers clang # compiler selection is broken,
this chooses /usr/bin/clang which works best with macport's portfiles
cxx_stdlib libstdc++ # configure.cxx_stdlib seems
broken, this fills in appropriate default
After that, darwin and ubuntu supply 'sed' in different locations, so
rather than edit 200 Portfiles, you can do this:
sudo ln -s /bin/sed /usr/bin/sed
and then you're up and running. Ports will at least start to build.
There are a number of hiccups, where the portfile logic does not allow a
path where the platform is other than "darwin" -- e.g. libuv, but these
are easy to spot and easy to fix if desired. Some things appear harder
to fix, like "m4" which I have not yet sorted out.
And then you can play around. I don't know if MacPorts on Ubuntu (or any
other flavour of Linux) will ever be popular, but you can at least get
started.
Best,
Ken
signature.asc
Description: Message signed with OpenPGP using AMPGpg
