installing MacPorts 2.6.2 on Ubuntu Linux 20.04

Fri May 1 02:58:01 UTC 2020

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 (ken.cunningham.webuse at gmail.com) 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 (ken.cunningham.webuse at gmail.com) 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200501/b5eff94b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200501/b5eff94b/attachment-0001.sig>