installing MacPorts 2.6.2 on Ubuntu Linux 20.04

Kenneth F. Cunningham ken.cunningham.webuse at gmail.com
Fri May 1 02:55:10 UTC 2020


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/20200430/4432b330/attachment-0001.html>


More information about the macports-dev mailing list