Re: Supporting installing arbitrary port versions

[Joshua Root]

On 2020-10-4 16:36 , Ryan Schmidt wrote:
> On Oct 3, 2020, at 23:40, Jason Liu wrote:
> 
>>> Just looking at your idea to distribute all portfile versions, let's start 
>>> with the fact that portfile syntax has evolved over time.
>>
>> This is where portfile syntax itself can, and probably should, be versioned. 
>> Maybe by incrementing PortSystem? i.e. PortSystem 1.3, 1.4, 2.0, etc. 
>> Similar to how the HTML standard specification's version number has changed 
>> over time, from HTML 2 all the way to the current HTML 5.
> 
> Yes, we could do that starting now, but since we haven't up to now, the 
> problem exists. The portsystem version concept was part of the original 
> MacPorts design, predating the involvement of everyone here, so we would have 
> to figure out how it works, whether it was ever fully implemented, what the 
> implications would be of increasing the version, etc.

It is implemented to the extent that "PortSystem $version" is a proc
call that runs "package require port $version". Keeping support for old
Portfiles would require keeping around old versions of the port package
and the other packages it requires, with the old code that the old
Portfiles rely upon (including problematic code; this would need to be
"bug for bug" compatibility.)

Linux distros don't support building their old packages from source in
arbitrary newer environments, they just let you install the package.
Given compatible versions of all the dependencies, that usually works,
because they are an entire OS and so they're targeting the Linux kernel
ABI which is quite stable.

- Josh

Re: Supporting installing arbitrary port versions

[Ryan Schmidt]

On Oct 3, 2020, at 23:40, Jason Liu wrote:

>> Just looking at your idea to distribute all portfile versions, let's start 
>> with the fact that portfile syntax has evolved over time.
> 
> This is where portfile syntax itself can, and probably should, be versioned. 
> Maybe by incrementing PortSystem? i.e. PortSystem 1.3, 1.4, 2.0, etc. Similar 
> to how the HTML standard specification's version number has changed over 
> time, from HTML 2 all the way to the current HTML 5.

Yes, we could do that starting now, but since we haven't up to now, the problem 
exists. The portsystem version concept was part of the original MacPorts 
design, predating the involvement of everyone here, so we would have to figure 
out how it works, whether it was ever fully implemented, what the implications 
would be of increasing the version, etc.


>> If MacPorts allowed the user to pick an arbitrary old Portfile to install, 
>> it is extremely likely that the user would experience an error.
>>  
>> If you are suggesting that we should not only distribute all old portfiles 
>> but also keep them all updated as needed, that would be a ludicrous amount 
>> of work that nobody would be willing to do.
> 
> This is where being able to restrict dependencies to specific version ranges 
> would be incredibly useful. If you could say that a portfile's dependency 
> requires a version >= 1.3.0 && <= 1.5.2, then you would not need to update 
> that old portfile once the dependency's portfile gets updated to a version 
> beyond 1.5.2.

I don't think I understand. Could you make the example more specific by using 
(real or made up) port names?


>> Well you spoke of keeping all Portfile versions. So perhaps you're 
>> suggesting the user should be able to select from any past version of the 
>> port. That's slightly more reasonable than allowing the user to request any 
>> version of the software regardless of whether that version has ever been in 
>> the portfile, but still completely impossible and unsupportable as far as I 
>> can see so far.
> 
> Other PMSes like APT and YUM do exactly that. They keep all versions of their 
> package's spec files. How they do this is that their package repositories 
> have a different architecture than how MacPorts is currently laid out.
> 
> [Note: What follows below is a fairly lengthy description of how another 
> package management system works. If you have no interest in such things, here 
> is probably a good place to stop reading.]

Thanks, I am interested to the extent that if someone else has a solution that 
would work for us, that would be good to know.

You've described how they keep their current and historical "Portfiles" on a 
server and download them on demand rather than keeping the current ones all 
pre-downloaded on the user's computer. But you haven't addressed how you could 
build historical "Portfiles" on a newer OS or compiler version when they would 
not have been written to account for the new restrictions imposed by that newer 
OS or compiler version, and we go back to my supposition that a portfile 
maintainer would be asked to keep updating and patching ever old versions of 
their portfile.

Re: Supporting installing arbitrary port versions (was: Re: port "cask" -- installing prebuilt binaries)

[Jason Liu]

> Just looking at your idea to distribute all portfile versions, let's start
> with the fact that portfile syntax has evolved over time.
>

This is where portfile syntax itself can, and probably should, be
versioned. Maybe by incrementing PortSystem? i.e. PortSystem 1.3, 1.4, 2.0,
etc. Similar to how the HTML standard specification's version number has
changed over time, from HTML 2 all the way to the current HTML 5.

If MacPorts allowed the user to pick an arbitrary old Portfile to install,
> it is extremely likely that the user would experience an error.
>

>
If you are suggesting that we should not only distribute all old portfiles
> but also keep them all updated as needed, that would be a ludicrous amount
> of work that nobody would be willing to do.
>

This is where being able to restrict dependencies to specific version
ranges would be incredibly useful. If you could say that a portfile's
dependency requires a version >= 1.3.0 && <= 1.5.2, then you would not need
to update that old portfile once the dependency's portfile gets updated to
a version beyond 1.5.2.

Well you spoke of keeping all Portfile versions. So perhaps you're
> suggesting the user should be able to select from any past version of the
> port. That's slightly more reasonable than allowing the user to request any
> version of the software regardless of whether that version has ever been in
> the portfile, but still completely impossible and unsupportable as far as I
> can see so far.
>

Other PMSes like APT and YUM do exactly that. They keep all versions of
their package's spec files. How they do this is that their package
repositories have a different architecture than how MacPorts is currently
laid out.

[Note: What follows below is a fairly lengthy description of how another
package management system works. If you have no interest in such things,
here is probably a good place to stop reading.]

Allow me to take the Blender package in the Debian repo as an example. Here
is the entry for Debian Testing, which is the version of Debian that I use
(Debian Stable tends to be a bit too outdated for my taste):

https://packages.debian.org/bullseye/blender

If you look at the info on the right side of that page, one of the sections
is "Download Source Package blender:". There are three items listed:

   - [blender_2.83.5+dfsg-2.dsc]
   
   - [blender_2.83.5+dfsg.orig.tar.xz]
   

   - [blender_2.83.5+dfsg-2.debian.tar.xz]
   


Before I go into further detail about the three items above, another
interesting thing to take a quick look at is the actual folder for the
Blender package on the Debian repo:

http://deb.debian.org/debian/pool/main/b/blender/

There you will see the three files I listed above, and also many .deb
files. Those .deb files are basically pre-compiled archives of the package,
which have been built for individual architectures e.g. amd64, i386, arm64,
etc. Now, let me go through each of the three items.

The first item, the .dsc file, is a Debian source control
 file. It is a text file that contains many
fields which would be quite familiar to anyone familiar with our portfiles.

The second item, the .orig.tar.xz file, is a copy of the upstream source
code. It's basically the equivalent of a MacPorts distfile, like what's
stored on https://distfiles.macports.org.

The third item, the .debian.tar.xz file, is the one that is the most
interesting. If we took the entire contents of this folder

https://github.com/macports/macports-ports/blob/master/graphics/blender/

and zipped it up into an archive, that would be the MacPorts equivalent to
the third item. If you extract the third item, you will find a debian/
folder that contains all of the spec files for the APT package of Blender.
In general, if you were to concatenate the two files "control" and "rules"
together into a single file, it would look a lot like our notion of a
portfile. The file called "control" will already look familiar: in fact,
this file is used to generate the .dsc file when the package gets built.
The "rules" file contains the equivalent of what we use in portfiles to
control the various phases of the MacPorts build process, e.g. pre-fetch,
post-patch, depends_lib, configure.args, post-destroot, etc.

Now, here is how an APT repository "keeps all Portfile versions". If you go
back and look at actual folder for the Blender package on the Debian repo:

http://deb.debian.org/debian/pool/main/b/blender/

you will see that there are multiple versions of Blender in that folder.
For each version, the three items I discussed are present, along with some
pre-compiled .deb archives. One of the most important ways in which an APT
or YUM repository differs from a MacPorts ports tree is this: what ki

Package managers and package versioning

[Jason Liu]

On Fri, Oct 2, 2020 at 9:00 PM Ryan Schmidt  wrote:

>
> On Oct 2, 2020, at 17:42, Lothar Haeger wrote:
>
>> Instead of creating separate copies of perl for each version, it would've
>> probably been smarter to fix the limitation in MacPorts that made this
>> workaround necessary, i.e. its inability to maintain and install all but
>> the latest version of a port. RPM can do it, DEB can do it, MSI can do it,
>> nothing unusual in the grand scheme of package managers in general to be
>> able to choose a specific version to install. Just MacPorts did not
>> implement it yet and when the necessity arose a seemingly simple workaround
>> was chosen instead of solving the underlying problem.
>>
>
> I have no familiarity with rpm, deb, msi, or other package managers so I
> cannot say whether or how they allow the user to select which version of a
> package to install.
>

Many modern package management systems give both package makers and users
the ability to specify version numbers, both for packages and for
dependencies. I call them "modern", because either they have only existed
for, say, 10 years or less, and were created from the very beginning with
version-choosing capabilities, or if they have been around for around 20
years or more, then they gained the ability one of two ways. Either the
ability was added as part of a complete rewrite of the package management
system, or it was added as a major new feature.

One of the most visible consequences of this ability is demonstrated by how
dependencies are specified. Giving users the ability to choose which
version of a package to install could very easily result in dependency
hell. Thus, to prevent this, dependencies also need to be able to have
version numbers specified:

   - RPM Guide: Specifying the Version of the Dependencies
   

   - ServerFault: RPM: Set Required: somepackage >= 0.5.0 AND sompackage <
   0.6.0
   


This results in package management systems with spec files that have
dependencies specified like this:

Requires: somepackage >= 0.5.0, somepackage < 0.6.0

I'm speaking of the user being able to specify an arbitrary version. If
> you're instead thinking that the port maintainer would specify a list of
> valid versions or something, that might be more feasible, but still not
> without some of the above problems.
>

APT has the ability to do this.  APT
is a package management system used by Debian, Ubuntu, and other flavors of
Linux that use .deb-based packages. To repeat what I just linked to, using
apt-get, a user can install a specific version of a package:

apt-get install apache2=2.2.20-1ubuntu1

YUM can also do this.

YUM is a package management system used by Red Hat Enterprise Linux,
CentOS, and other flavors of Linux that use RPM-based packages. To repeat
what I just linked to, using yum:

yum install firefox-31.5.3-3.el7_1.x86_64

NPM and Yarn, which are PMSes for JavaScript packages, were created with
package versioning capabilities as a feature right from their very
beginnings:

   - Yarn: Version ranges
   
   - NPM/Greenkeeper: Introduction to Version Ranges
   
   - NPM: Specifying dependencies and devDependencies in a package.json file
   


This results in the possibility of restricting dependencies to very
specific version numbers, like this:

1.4.0-1.5.2 || >=1.5.6 <2.4.0 : Matches version 1.4.0 through 1.5.2, and
1.5.7, but not 1.5.3, 1.5.4, or 2.4.0

I can't currently remember which one at the moment, but I seem to vaguely
recall that the syntax for a certain package manager looked something like:

 install apache2 @2.2.20-1ubuntu1

which, it seems, looks very close to a syntax that would fit MacPorts. For
example, perhaps something like this might be a nice syntax if such a
feature were to be added to MacPorts:

port install vlc @5.0.6 +jack +svg +shout

and in portfiles, something like this for dependency version ranges might
make sense:

depends_lib port:boost >=1.67.0 +cmake_scripts +python37|python38
-mpich_devel \
port:openexr >=1.7.4_3,<2.7.1_2

(this example also includes a capability on my personal wish-list: the
ability to specify a dependency to be installed with/without a certain set
of variants, but without needing to resort to things like using the
active_variants PortGroup or require_active_variants)

As for MacPorts, it's not that we haven't implemented it because we're
> lazy. It's because, besides being 

Re: [MacPorts] #61267: Error in mysqld_safe from mysql8-server

[Herby G]

Did you do the initial set up?

You can take a look at the log in /opt/local/var/log/mysql

On Sat, Oct 3, 2020, 15:11 Murray Eisenberg  wrote:

> Something seems to be wrong:
>
> sudo port load mysql8-server
> -->  Loading startupitem 'mysql8-server' for mysql8-server
>
> ps -ax | grep mysql
> 39298 ttys0010:00.00 grep mysql
>
> Is the mysql8 server actually running??
>
> Should there be a process found for mysqld?
>
> On 3 Oct2020, at 1:52 PM, Herby G  wrote:
>
> Hello Murray,
>
> Instructions for setting up mysql8-server after installation with MacPorts
> are shown in the console right after installation.
>
> You can review these using 'port notes':
>
> $ port notes mysql8-server
>
> Then you would start the mysql8-server service using 'port load':
>
> $ sudo port load mysql8-server
>
> To stop and disable the service, use 'port unload':
>
> $ sudo port unload mysql8-server
>
> On Sat, Oct 3, 2020, 13:38 MacPorts  wrote:
>
>> #61267: Error in mysqld_safe from mysql8-server
>> --+---
>>  Reporter:  murrayE   |  Owner:  (none)
>>  Type:  defect| Status:  new
>>  Priority:  Normal|  Milestone:
>> Component:  ports |Version:  2.6.3
>>  Keywords:  syntax error  |   Port:  mysql8-server
>> --+---
>>  After installing mysql8-server, I tried running it with command:
>>
>>  {{{
>>  sudo /opt/local/share/mysql8/support-files/mysql.server start
>>  }}}
>>
>>  After the prompt for, and giving, my password, the following happens:
>>
>>  {{{
>>  Starting MySQL
>>  ./opt/local/bin/mysqld_safe: line 810: syntax error near unexpected token
>>  `then'
>>  /opt/local/bin/mysqld_safe: line 810: `then# The pid contains a
>>  mysqld process'
>>   ERROR! The server quit without updating PID file
>>  (/opt/local/var/run/mysqld/mysqld.pid).
>>  }}}
>>
>> --
>> Ticket URL: 
>> MacPorts 
>> Ports system for macOS
>>
>
> ——
> Murray Eisenbergmur...@math.umass.edu
> Professor Emeritus
> Mathematics & Statistics Dept.
> University of Massachusetts
> Amherst, MA USA
>
>
>
>
>
>

Re: How to abort a macports portfile on an error condition?

[Ken Cunningham]

Martin, I'm trying to understand how this is happening to you.

you should not need to be doing that in your Portfile, and users should never 
need to make that symlink.

The linuxdoc-tools port has this:

depends_build   bin:latex:texlive \
path:bin/perl:perl5


But it seems that you're saying that perl5 is not just a build dep, but also a 
runtime dep?

If so, if we change that part to:

depends_lib path:bin/perl:perl5

Then that will force perl5 to be available at runtime as well.

Is that the proper fix?

Ken


> That's. That worked. Preparing a pull request.
> 
> Eric F schrieb:
> > Try using “return -code error”, something like:
> > 
> > ```tlc
> > if {![file exists ${prefix}/bin/perl]} {
> > ui_error "
> > «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
> > 
> > Please create an appropriate symbolic link for linuxdoc-tools to work.
> > "
> > return -code error "missing dependency"
> > }
> > ```
> > 
> > · Eric
> > 
> > On 10/3/20 11:15 , Martin Krischik wrote:
> >> Hello,
> >>
> >> I working on a version bump on the **cc65** and encountered a problem
> >> with the **linuxdoc-tools**. Since I can't fix the **linuxdoc-tools**
> >> and there is a simple workaround possible I decided to add an if
> >> statement to inform the user together with the workaround:
> >>
> >> ```tlc
> >>if {! [file exists ${prefix}/bin/perl] } {
> >>ui_error "
> >> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
> >>
> >> Please create an appropriate symbolic link for linuxdoc-tools to work.
> >> "
> >>exit 1
> >>}
> >> ```
> >>
> >> Crude but the best I can do since I'm neither the **perl5** nor the
> >> **linuxdoc-tools** maintainer and I don't want to spend to much time on
> >> a otherwise simple version bump.
> >>
> >> However, the MacPorts doesn't understand `exit 1` and `ui_error` won't
> >> stop execution on its own.
> >>
> >> How do I stop the execution so not to waste the users time on a build
> >> which will otherwise fail right at the end.
> >>
> >> Regards
> >>
> >> Martin
> > 

Re: How to abort a macports portfile on an error condition?

[Martin Krischik]

That's. That worked. Preparing a pull request.

Eric F schrieb:
> Try using “return -code error”, something like:
> 
> ```tlc
> if {![file exists ${prefix}/bin/perl]} {
> ui_error "
> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
> 
> Please create an appropriate symbolic link for linuxdoc-tools to work.
> "
> return -code error "missing dependency"
> }
> ```
> 
> · Eric
> 
> On 10/3/20 11:15 , Martin Krischik wrote:
>> Hello,
>>
>> I working on a version bump on the **cc65** and encountered a problem
>> with the **linuxdoc-tools**. Since I can't fix the **linuxdoc-tools**
>> and there is a simple workaround possible I decided to add an if
>> statement to inform the user together with the workaround:
>>
>> ```tlc
>>  if {! [file exists ${prefix}/bin/perl] } {
>>  ui_error "
>> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
>>
>> Please create an appropriate symbolic link for linuxdoc-tools to work.
>> "
>>  exit 1
>>  }
>> ```
>>
>> Crude but the best I can do since I'm neither the **perl5** nor the
>> **linuxdoc-tools** maintainer and I don't want to spend to much time on
>> a otherwise simple version bump.
>>
>> However, the MacPorts doesn't understand `exit 1` and `ui_error` won't
>> stop execution on its own.
>>
>> How do I stop the execution so not to waste the users time on a build
>> which will otherwise fail right at the end.
>>
>> Regards
>>
>> Martin
> 

-- 
Martin Krischik
mailto://krisc...@users.sourceforge.net
https://sourceforge.net/users/krischik
https://github.com/krischik

Re: [MacPorts] #61267: Error in mysqld_safe from mysql8-server

[Herby G]

Hello Murray,

Instructions for setting up mysql8-server after installation with MacPorts
are shown in the console right after installation.

You can review these using 'port notes':

$ port notes mysql8-server

Then you would start the mysql8-server service using 'port load':

$ sudo port load mysql8-server

To stop and disable the service, use 'port unload':

$ sudo port unload mysql8-server

On Sat, Oct 3, 2020, 13:38 MacPorts  wrote:

> #61267: Error in mysqld_safe from mysql8-server
> --+---
>  Reporter:  murrayE   |  Owner:  (none)
>  Type:  defect| Status:  new
>  Priority:  Normal|  Milestone:
> Component:  ports |Version:  2.6.3
>  Keywords:  syntax error  |   Port:  mysql8-server
> --+---
>  After installing mysql8-server, I tried running it with command:
>
>  {{{
>  sudo /opt/local/share/mysql8/support-files/mysql.server start
>  }}}
>
>  After the prompt for, and giving, my password, the following happens:
>
>  {{{
>  Starting MySQL
>  ./opt/local/bin/mysqld_safe: line 810: syntax error near unexpected token
>  `then'
>  /opt/local/bin/mysqld_safe: line 810: `then# The pid contains a
>  mysqld process'
>   ERROR! The server quit without updating PID file
>  (/opt/local/var/run/mysqld/mysqld.pid).
>  }}}
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS
>

Re: Supporting installing arbitrary port versions (was: Re: port "cask" -- installing prebuilt binaries)

[Ryan Schmidt]

On Oct 3, 2020, at 06:05, Lothar Haeger wrote:

>> It's because, besides being an unimaginably large amount of work in 
>> rearranging our code to do it, I have absolutely no idea how it would be 
>> accomplished without providing the user with unlimited opportunities to 
>> create broken combinations of port versions, which would generate an 
>> unlimited number of bug reports that we would then need to respond to, and 
>> my goal in MacPorts is to reduce, not increase, the likelihood that users 
>> would find something broken or need to contact us to help troubleshoot it.
>> 
>> If you have an idea for how it could be done without such problems arising, 
>> please open a new topic and describe it and we can talk through a few 
>> scenarios and see if it works.
> 
> I do have some ideas (not mine, just looking at how it works elsewhere), but 
> not the time to drive something of this size, to be honest. Basically, we'd 
> need to 
> - keep and distribute all Portfile versions (including patches and files), 
> not just the lastest
> - add required versions to dependencies (can be version ranges e.g. >=1.2.3 
> or 2.* or 1.2.3-4.5.6)
> - add support to install individual ports in into separate folders or give 
> them individual names on install time (much like with the perl versions), so 
> multiple versions of a port can be installed in parallel.
> - add command line parameters to the port command so users can optionally 
> specify a version to install (defaults to latest) and a pre/post fix to 
> install location or file names or both (depends on how stuff gets 
> implemented, of course)
> - add support for dependency resolution including version information. So if 
> two ports have different, non overlapping version requirements for a 
> dependency, that dependency gets installed twice. Making sure each port then 
> actually uses its matching version is probably one of the trickier parts here.
> 
> Implementing all this would be a major project and I totally understand that 
> it's nothing to jump at without considering all the consequences and outside 
> factors. 

It would be a major project if it were clear how it could possibly work and it 
were just a matter of doing it. But so far I have no idea how it could work.

Just looking at your idea to distribute all portfile versions, let's start with 
the fact that portfile syntax has evolved over time. A portfile from ten years 
ago can't even necessarily be parsed by today's MacPorts ("livecheck.type" used 
to be called "livecheck.check"; there used to be "cd" and "suffix" procedures 
that ports used to use) or it may behave differently than it did then 
("platform" blocks used to behave like variants and their code was evaluated at 
the end of the portfile rather than where it's declared; the way that the 
arguments of startupitems and configure.env/build.env/etc need to be quoted was 
changed).

Libraries change over time. Sometimes when a library changes it means that the 
other ports that use that library need to be patched. Obviously those patches 
were not in the old versions of the portfile that predate the new library, and 
patches for the current version of the software couldn't necessarily be used on 
old versions without being rewritten.

Compilers and operating systems evolve. Xcode 12, for example, prohibits 
implicitly declared functions. We're adding patches to ports as fast as we can 
to fix these problems, but old versions of the portfile would not have those 
patches.

If MacPorts allowed the user to pick an arbitrary old Portfile to install, it 
is extremely likely that the user would experience an error.

If you are suggesting that we should not only distribute all old portfiles but 
also keep them all updated as needed, that would be a ludicrous amount of work 
that nobody would be willing to do.


>> I'm speaking of the user being able to specify an arbitrary version.
> 
> So do I.

Well you spoke of keeping all Portfile versions. So perhaps you're suggesting 
the user should be able to select from any past version of the port. That's 
slightly more reasonable than allowing the user to request any version of the 
software regardless of whether that version has ever been in the portfile, but 
still completely impossible and unsupportable as far as I can see so far.


>> I consider it a feature, not a bug, that we offer multiple ports for 
>> different versions of perl, php, python, ruby, gcc, clang. It enables the 
>> user to install multiple versions of those languages that can all be active 
>> and available at the same time. If the user has one script that works with 
>> python 3.8 and another that requires python 3.6, no problem. If they have 
>> one web site that works with php 7.4 and another that needs php 7.2, no 
>> problem. If we only had a single python or php port that only let the user 
>> choose a single version to install at a time, that would not be possible.
> 
> I totally agree that this is a great feature. Only

Re: port "cask" -- installing prebuilt binaries

[Ken Cunningham]

Ok.

So contenders for the metadata identifying non-buildable binary-only ports we 
have:

name suffix (like the hs- ports had)
category only
variant as identifier

We have spent far too long on this nonsense. Some admin pick one, then lets 
move on.

K

Re: port "cask" -- installing prebuilt binaries

[Lothar Haeger]

> Am 03.10.2020 um 03:00 schrieb Ryan Schmidt :
> 
> Lothar, I agree with most of your reasoning for why a variant is a reasonable 
> choice for indicating a prebuilt binary. I am less concerned with how to 
> indicate prebuilt status than I am with whether we should do it at all.

Interesting, back to the very beginning… 

I kind of already accepted that an indicator should be found, not questioning 
is usefulness anymore. Personally I do not care much about it, but obviously 
others do and in general additional information is considered a good thing, so 
why not add it? All I really care about in this context is, that however we 
implement it, no existing or easily conceivable future feature will suffer from 
it. 

Re: port "cask" -- installing prebuilt binaries

[Lothar Haeger]

Ryan,

> Am 03.10.2020 um 03:00 schrieb Ryan Schmidt :
> 
>> Just MacPorts did not implement it yet and when the necessity arose a 
>> seemingly simple workaround was chosen instead of solving the underlying 
>> problem.
> 
> As for MacPorts, it's not that we haven't implemented it because we're lazy. 

my apologies for expressing this poorly enough to be misunderstood. I did not 
mean to suggest laziness was a reason to chose one way over another, neither in 
this case nor in general. 

> It's because, besides being an unimaginably large amount of work in 
> rearranging our code to do it, I have absolutely no idea how it would be 
> accomplished without providing the user with unlimited opportunities to 
> create broken combinations of port versions, which would generate an 
> unlimited number of bug reports that we would then need to respond to, and my 
> goal in MacPorts is to reduce, not increase, the likelihood that users would 
> find something broken or need to contact us to help troubleshoot it.
> 
> If you have an idea for how it could be done without such problems arising, 
> please open a new topic and describe it and we can talk through a few 
> scenarios and see if it works.

I do have some ideas (not mine, just looking at how it works elsewhere), but 
not the time to drive something of this size, to be honest. Basically, we'd 
need to 
- keep and distribute all Portfile versions (including patches and files), not 
just the lastest
- add required versions to dependencies (can be version ranges e.g. >=1.2.3 or 
2.* or 1.2.3-4.5.6)
- add support to install individual ports in into separate folders or give them 
individual names on install time (much like with the perl versions), so 
multiple versions of a port can be installed in parallel.
- add command line parameters to the port command so users can optionally 
specify a version to install (defaults to latest) and a pre/post fix to install 
location or file names or both (depends on how stuff gets implemented, of 
course)
- add support for dependency resolution including version information. So if 
two ports have different, non overlapping version requirements for a 
dependency, that dependency gets installed twice. Making sure each port then 
actually uses its matching version is probably one of the trickier parts here.

Implementing all this would be a major project and I totally understand that 
it's nothing to jump at without considering all the consequences and outside 
factors. 

> I'm speaking of the user being able to specify an arbitrary version.

So do I.

> I consider it a feature, not a bug, that we offer multiple ports for 
> different versions of perl, php, python, ruby, gcc, clang. It enables the 
> user to install multiple versions of those languages that can all be active 
> and available at the same time. If the user has one script that works with 
> python 3.8 and another that requires python 3.6, no problem. If they have one 
> web site that works with php 7.4 and another that needs php 7.2, no problem. 
> If we only had a single python or php port that only let the user choose a 
> single version to install at a time, that would not be possible.

I totally agree that this is a great feature. Only it's limited to a few 
versions of a few ports due to the way it's being implemented. Supporting this 
for more ports and version does not scale well, twice as many ports/versions 
cause twice as much work. With thousands of ports in the tree the current 
approach will always be limited to a handful of ports. If this was implemented 
as general features to a) install any port version and b) install several 
instances of any port, we'd get the same for each and every port/version out of 
the box.

Re: How to abort a macports portfile on an error condition?

[Nils Breunese]

There is also ‘known_fail yes’, which I see getting combined with ‘return -code 
error’: https://trac.macports.org/ticket/60566

I’m not familiar with the precise differences between known_fail, ui_error and 
return -code error.

Nils.

> Op 3 okt. 2020, om 12:30 heeft Eric F  het volgende 
> geschreven:
> 
> Try using “return -code error”, something like:
> 
> ```tlc
> if {![file exists ${prefix}/bin/perl]} {
> ui_error "
> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
> 
> Please create an appropriate symbolic link for linuxdoc-tools to work.
> "
> return -code error "missing dependency"
> }
> ```
> 
> · Eric
> 
> On 10/3/20 11:15 , Martin Krischik wrote:
>> Hello,
>> 
>> I working on a version bump on the **cc65** and encountered a problem
>> with the **linuxdoc-tools**. Since I can't fix the **linuxdoc-tools**
>> and there is a simple workaround possible I decided to add an if
>> statement to inform the user together with the workaround:
>> 
>> ```tlc
>>  if {! [file exists ${prefix}/bin/perl] } {
>>  ui_error "
>> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
>> 
>> Please create an appropriate symbolic link for linuxdoc-tools to work.
>> "
>>  exit 1
>>  }
>> ```
>> 
>> Crude but the best I can do since I'm neither the **perl5** nor the
>> **linuxdoc-tools** maintainer and I don't want to spend to much time on
>> a otherwise simple version bump.
>> 
>> However, the MacPorts doesn't understand `exit 1` and `ui_error` won't
>> stop execution on its own.
>> 
>> How do I stop the execution so not to waste the users time on a build
>> which will otherwise fail right at the end.
>> 
>> Regards
>> 
>> Martin
>> 
> 

Re: How to abort a macports portfile on an error condition?

[Eric F]

Try using “return -code error”, something like:

```tlc
if {![file exists ${prefix}/bin/perl]} {
ui_error "
«${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.

Please create an appropriate symbolic link for linuxdoc-tools to work.
"
return -code error "missing dependency"
}
```

· Eric

On 10/3/20 11:15 , Martin Krischik wrote:
> Hello,
>
> I working on a version bump on the **cc65** and encountered a problem
> with the **linuxdoc-tools**. Since I can't fix the **linuxdoc-tools**
> and there is a simple workaround possible I decided to add an if
> statement to inform the user together with the workaround:
>
> ```tlc
>   if {! [file exists ${prefix}/bin/perl] } {
>   ui_error "
> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
>
> Please create an appropriate symbolic link for linuxdoc-tools to work.
> "
>   exit 1
>   }
> ```
>
> Crude but the best I can do since I'm neither the **perl5** nor the
> **linuxdoc-tools** maintainer and I don't want to spend to much time on
> a otherwise simple version bump.
>
> However, the MacPorts doesn't understand `exit 1` and `ui_error` won't
> stop execution on its own.
>
> How do I stop the execution so not to waste the users time on a build
> which will otherwise fail right at the end.
>
> Regards
>
> Martin

How to abort a macports portfile on an error condition?

[Martin Krischik]

Hello,

I working on a version bump on the **cc65** and encountered a problem
with the **linuxdoc-tools**. Since I can't fix the **linuxdoc-tools**
and there is a simple workaround possible I decided to add an if
statement to inform the user together with the workaround:

```tlc
if {! [file exists ${prefix}/bin/perl] } {
ui_error "
«${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.

Please create an appropriate symbolic link for linuxdoc-tools to work.
"
exit 1
}
```

Crude but the best I can do since I'm neither the **perl5** nor the
**linuxdoc-tools** maintainer and I don't want to spend to much time on
a otherwise simple version bump.

However, the MacPorts doesn't understand `exit 1` and `ui_error` won't
stop execution on its own.

How do I stop the execution so not to waste the users time on a build
which will otherwise fail right at the end.

Regards

Martin
-- 
Martin Krischik
mailto://krisc...@users.sourceforge.net
https://sourceforge.net/users/krischik
https://github.com/krischik