<html><head><style>body{font-family:Merriweather,Arial;font-size:13px}</style></head><body><div style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); ">Sure, sure, </div><div style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); "><br></div><div style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); ">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! </div> <br> <div class="gmail_signature"><pre><code> _
-. .´ |∞∞∞∞
', ; |∞∞∞∞∞∞
˜˜ |∞∞∞∞∞∞∞∞∞ RdB
,., |∞∞∞∞∞∞
.' '. |∞∞∞∞
-' `’
https://rdb.is
</code></pre></div> <br><p class="airmail_on">On 1 May 2020 at 04:55:14, Kenneth F. Cunningham (<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div></div><div><base href="x-msg://1/">You could be correct.<div><br></div><div>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.</div><div><br></div><div>That's all the "platform darwin" stuff in all the Portfiles and in base.</div><div><br></div><div>I was just curious if MacPorts actually did work on Linux, and -- it turns out -- it does, with minor surgery.</div><div><br></div><div>So we're not really "making" it cross-platform; it always has been. </div><div><br></div><div>I was just more seeing if it truly worked.</div><div><br></div><div>K</div><div><br></div><div><br></div><div><br><div><div>On 2020-04-30, at 7:07 PM, Ruben Di Battista wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="font-family: Merriweather, Arial; font-size: 13px; "><div style="font-family: Merriweather, Arial; font-size: 13px; color: rgb(51, 51, 51); "><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Can I express a thought about this? :) I hope I won’t result too naive. </div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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: </div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Pacman on Arch provides pre-compiled binaries plus the AUR repository of packages that can be compiled at will (variants are missing, tho)</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Nix, that I think it's probably the most "correct" package manager currently available over there. </div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Spack, something like Nix, but optimized for HPC (so cross-compiling, architecture optimization and so on).</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">but I'm surely missing other cool projects. </div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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). </div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IMHO Macports should focus into potentiating the major selling points it has, again I pick something I have in mind myself:</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> </div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Native build of libraries and its dependencies</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Compatibility with old macOS versions</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Vast Linux and Unix selection of packages</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">and improve some aspects that could be improved:</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Abandon (not abruptly…) TCL for a more modern language, possibly more mainstream, that could enlarge the audience of possible contributors for packages</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Is the core written in C? I even don't know, but if it is, is it needed for performance reasons?</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Improve compatibility and performances of "Linux-polarized" libraries (e.g. Inkscape and GTK stuff)</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* Provide pre-compiled binaries also for variants to speedup installation for non-dev users</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">* 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...)</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="color: rgb(51, 51, 51); margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</div><div><br></div></div><br><div class="gmail_signature"><pre><code> _
-. .´ |∞∞∞∞
', ; |∞∞∞∞∞∞
˜˜ |∞∞∞∞∞∞∞∞∞ RdB
,., |∞∞∞∞∞∞
.' '. |∞∞∞∞
-' `’
<a href="https://rdb.is">https://rdb.is</a>
</code></pre></div><br><p class="airmail_on">On 1 May 2020 at 03:37:28, Ken Cunningham (<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>) wrote:</p><blockquote type="cite" class="clean_bq"><span><div><div></div><div>I thought I would start up a short thread on progress with this --<span class="Apple-converted-space"> </span><br>MacPorts on Linux. We've long written the Portfiles with this in mind.<span class="Apple-converted-space"> </span><br>This was done on an Intel system, with the current Ubuntu 20.04. Ubuntu<span class="Apple-converted-space"> </span><br>19.10 can be installed in a VM in parallels, and no doubt in other VM<span class="Apple-converted-space"> </span><br>systems.<span class="Apple-converted-space"> </span><br><br>Some quick notes:<span class="Apple-converted-space"> </span><br><br>apt is the built-in package manager, similar to "port".<span class="Apple-converted-space"> </span><br><br>"sudo apt install" is the same as "sudo port install".<span class="Apple-converted-space"> </span><br><br>"apt info" is "port info"<span class="Apple-converted-space"> </span><br><br>"apt-file show" does something similar to "port contents", but the<span class="Apple-converted-space"> </span><br>software does not have to be installed.<span class="Apple-converted-space"> </span><br><br><br>After downloading the MacPorts source tarball, and prior to building<span class="Apple-converted-space"> </span><br>MacPorts, you must install the supporting software that comes already on<span class="Apple-converted-space"> </span><br>Macs that MacPorts expects to find.<span class="Apple-converted-space"> </span><br><br>These were installed as:<span class="Apple-converted-space"> </span><br><br>sudo apt install mtree-netbsd<span class="Apple-converted-space"> </span><br>sudo apt install tcl8.6<span class="Apple-converted-space"> </span><br>sudo apt install curl<span class="Apple-converted-space"> </span><br>sudo apt install sqlite3<span class="Apple-converted-space"> </span><br>sudo apt install gnustep<span class="Apple-converted-space"> </span><br>sudo apt install libcurl4-gnutls-dev<span class="Apple-converted-space"> </span><br>sudo apt install libsqlite3-dev<span class="Apple-converted-space"> </span><br><br><br>my system already had llvm-10 and clang-10 installed, and there was<span class="Apple-converted-space"> </span><br>already a symlink "port" linking /usr/bin/clang to the selected clang<span class="Apple-converted-space"> </span><br>binary, in this case clang-10.<span class="Apple-converted-space"> </span><br><br>Then build and install MacPorts as usual, into /opt/local<span class="Apple-converted-space"> </span><br><br>./configure && make && sudo make install<span class="Apple-converted-space"> </span><br><br><br>Add to your PATH as usual, but on Ubuntu, by editing ".bashrc", adding:<span class="Apple-converted-space"> </span><br><br>export PATH=/opt/local/bin:/opt/local/sbin:$PATH<span class="Apple-converted-space"> </span><br><br><br>Adding that PATH to the sudo command is harder -- it doesn't pick it up<span class="Apple-converted-space"> </span><br>from the above ".bashrc". You have add it to the sudoers command with:<span class="Apple-converted-space"> </span><br><br>sudo visudo<span class="Apple-converted-space"> </span><br><br>and then add it to the secure_path<span class="Apple-converted-space"> </span><br><br>Defaults<span class="Apple-converted-space"> </span><br>secure_path="/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"<span class="Apple-converted-space"> </span><br><br>There are some differences between Darwin and Ubuntu, and to work around<span class="Apple-converted-space"> </span><br>some of these that are not already compensated for by MacPorts base, I<span class="Apple-converted-space"> </span><br>did this:<span class="Apple-converted-space"> </span><br><br><br>edit macports.conf<span class="Apple-converted-space"> </span><br><br>sudo gedit /opt/local/etc/macports/macports.conf<span class="Apple-converted-space"> </span><br><br>and add:<span class="Apple-converted-space"> </span><br><br>buildmakejobs 2 # or a more appropriate<span class="Apple-converted-space"> </span><br>number for your processor count<span class="Apple-converted-space"> </span><br>default_compilers clang # compiler selection is broken,<span class="Apple-converted-space"> </span><br>this chooses /usr/bin/clang which works best with macport's portfiles<span class="Apple-converted-space"> </span><br>cxx_stdlib libstdc++ # configure.cxx_stdlib seems<span class="Apple-converted-space"> </span><br>broken, this fills in appropriate default<span class="Apple-converted-space"> </span><br><br><br>After that, darwin and ubuntu supply 'sed' in different locations, so<span class="Apple-converted-space"> </span><br>rather than edit 200 Portfiles, you can do this:<span class="Apple-converted-space"> </span><br><br>sudo ln -s /bin/sed /usr/bin/sed<span class="Apple-converted-space"> </span><br><br><br>and then you're up and running. Ports will at least start to build.<span class="Apple-converted-space"> </span><br>There are a number of hiccups, where the portfile logic does not allow a<span class="Apple-converted-space"> </span><br>path where the platform is other than "darwin" -- e.g. libuv, but these<span class="Apple-converted-space"> </span><br>are easy to spot and easy to fix if desired. Some things appear harder<span class="Apple-converted-space"> </span><br>to fix, like "m4" which I have not yet sorted out.<span class="Apple-converted-space"> </span><br><br><br>And then you can play around. I don't know if MacPorts on Ubuntu (or any<span class="Apple-converted-space"> </span><br>other flavour of Linux) will ever be popular, but you can at least get<span class="Apple-converted-space"> </span><br>started.<span class="Apple-converted-space"> </span><br><br><br>Best,<span class="Apple-converted-space"> </span><br><br><br>Ken<span class="Apple-converted-space"> </span><br><br><br><br></div></div></span></blockquote></div></span></blockquote></div><br></div></div></div></span></blockquote></body></html>