Re: Package managers and package versioning
> > It's my understanding, for example, that Homebrew allows the user to > request to install the git master of a particular Homebrew formula, in > effect allowing the user to (try to) install a version of the software that > was never previously attempted by the formula's creator. This is what I was > afraid was part of what was being proposed, and something I would not > support adding to MacPorts. > I'm not that familiar with Homebrew, so this is the first time I'm hearing about this sort of capability. None of the other PMSes that I have experience with can do this. The idea of being able to (try to) install a version of a package that doesn't even exist in a repository's metadata database sounds insane to me. If we continue the liberal approach with dependencies, then we begin from > the assumption that a port can use any version of a dependency. Let's say > libpng declares it can use any version of zlib. Then years later zlib 2 is > released and it is incompatible, breaking all versions of libpng we've > published. There's now a lot of work to go edit each previous libpng to > indicate that it requires zlib < 2. > #!/bin/bash for f in libpng/Portfile-*; do sed -i -e s/(port:zlib.*)$/\1 < 2/ $f done I'm probably missing some backslashes, but I think you probably get the idea. That doesn't seem like that much work to me. Alternatively, suppose we use the conservative approach and declare that > libpng requires zlib < 2. Or zlib < 1.3. Or zlib < 1.2.12. We have no way > to know in what future version of zlib, if any, incompatibility might > arise. Suppose we declare compatibility with zlib < 2, and years later zlib > 2 comes along and maintains perfect backward compatibility with zlib 1. > Then our libpng would continue to use the old zlib 1, even though it would > work with zlib 2, thus making users use outdated dependencies unnecessarily > and possibly exposing them to bugs that have already been fixed in newer > versions. And the solution then is to do a lot of work to go edit each > previous libpng to update its zlib compatibility list. > A sed statement wrapped inside a for loop would probably also help in this case. Either way, it's signing all port maintainers up for a lot of work. (Many > port maintainers already don't do the currently expected amount of work to > maintain their ports.) And all for the benefit of other ports being able to > declare that they require an old version of libpng. We did have this > problem once before, when some old ports were not compatible with libpng > 1.4 when it came out. Rather than introducing a libpng12 compatibility > port, we did the right thing and fixed other software to be compatible with > libpng 1.4. If we had used a libpng12 port instead, we likely would never > have noticed if and when those ports gained libpng 1.4 compatibility and > would be forcing libpng12 on users unnecessarily for years to come. > However, I feel like this would be a good example of why having multiple versions of a package's portfile available could be beneficial. Let's say libpng 1.4 came out and it broke a bunch of old ports. If previous versions of the portfile were available, like what I showed in my example of the Blender Debian package, then it would be very easy to simply remove the libpng 1.4 portfile from the repository, and all of the ports that were broken would suddenly be fine again, because they would just go back to using whichever portfile for libpng was already there. No need to increase the epoch inside the portfile to try to back-rev to an older version of libpng, no need to create a libpng12 compatibility port. And the port maintainers would be able to go right back to working on fixing ports locally on their test machines, without having to worry that the actual global ports tree had been broken for users. (By the way, this is why most flavors of Linux have multiple release channels, typically "stable", "testing", and "unstable". Each release channel has its own PMS repository, to avoid the situation where the global repository that users use gets polluted due to a package incompatibility.) And all for the benefit of other ports being able to declare that they > require an old version of libpng. > If there's really such little benefit, then why are we even having such a discussion? And why are there other PMSes which have this ability? Because they enjoy torturing their package maintainers with lots of busy work? Somehow I doubt it They wouldn't have gone to all the trouble of adding such a feature unless it was able to reduce the amount of work they had to do in some way. This is one place where MacPort's activate/deactivate would really shine: >> If someone wanted to install an old package, MacPorts would first >> deactivate all of the dependencies that were too new, and then install the >> old versions of the dependencies that are compatible with the old package. >> > > If all versions of a port install to the same location on disk
Re: How to abort a macports portfile on an error condition?
hey, thanks Ryan for taking care of this little detail.
K
On 2020-10-03, at 11:48 AM, Ken Cunningham wrote:
> 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: waf.python configurable?
On Oct 4, 2020, at 16:08, Zhenfu Shi wrote:
> I’m working on mpv portfile but I couldn’t find a way to change {waf.python},
> the python executable needed for waf. It’s currently failing to configure on
> buildbots. In https://trac.macports.org/ticket/57927 the original maker of
> waf portgroup said it is configurable. Anyone knows how?
It can't currently be done. I'll see if I can improve the portgroup to make it
possible.
Re: Supporting installing arbitrary port versions
On Sun, Oct 4, 2020 at 9:15 PM Ryan Schmidt wrote:
>
>
>
> On Oct 4, 2020, at 06:02, Ruben Di Battista wrote:
>
> > Is this something that really needs to be implemented from scratch?
> > There are other package managers that do this and are build to do this
> > (nix and spack come to mind). I don't know the difficulties of what
> > I'm going to propose, but wouldn't it be maybe easier to write a TCL
> > Lexer/Parser that allows to translate the TCL files to input files for
> > the other package managers and then tweak the `port` command to use
> > those package managers under the hoods? I'm a bit closer to spack
> > development, and they developed a concretizer
> > (https://archive.fosdem.org/2020/schedule/event/dependency_solving_not_just_sat/)
> > for the spec of the packages that took multiple years of work to be
> > finalized.
>
> So now you want MacPorts to become a wrapper around another system? That
> would be another colossal task, I don't know what the benefit of it would be,
> and it doesn't get us any closer to solving the previous colossal tasks I
> mentioned that stand in the way of being able to offer arbitrary versions and
> variants of all ports simultaneously, if that were something we wanted.
>
>
> > Personally I don't like the idea of shipping all package versions,
> > because there are already pieces of software developed for the same
> > reason and that, possibly, will do a better job than whatever Macports
> > will ever be able to do.
>
> ...then why are you suggesting the above?
I was just suggesting it since that was the discussion flow. Then, I
expressed my own 2¢ opinion. :)
>
> > For me the Macports scope must be kept
> > focused and small: installing (possibly latest versions of)
> > open-source stacks from source keeping compatibility with old systems
> > in the best way possible. There are already improvements that can be
> > done UX-wise keeping this same scope: two that come to (my) mind are:
> > - Using another DSL/Language for Portfile that is easier, more
> > flexible, and modern (e.g. Python)
>
> https://trac.macports.org/wiki/FAQ#whytcl explains why Tcl was chosen.
I read these. I understand the choices made at that time, but I think
~20 years later maybe they will be less applicable. For example, maybe
one of the aspects to take into account would be "newcomer
contributors friendliness", since I don't think most of the people
that want to contribute to Macports are proficient in TCL. I did not
run numbers, so I might be wrong. It's more likely they would be in
Python (just to say one), or Node.js, or whatever.
> For example, one benefit is the avoidance of a preponderance of symbols
> needed for basic tasks.
>
> In its most pure form, a portfile sets variables to values. In Tcl with the
> way that MacPorts has enhanced it, that can be accomplished in the simplest
> possible way:
>
> name zlib
>
> sets the variable "name" to the string "zlib". Can you do it that concisely
> in Python? Don't you instead have to write:
>
> name='zlib'
>
> Isn't that going to get old really quickly when you have to set a dozen or
> more variables in each portfile?
Well, it's three character strings difference. But I find this
(https://github.com/spack/spack/blob/977117b502589886fb5833340ab6cf1c15b3b26e/var/spack/repos/builtin/packages/paraview/package.py#L139):
```
if version < Version('5.1.0'):
[...]
```
way more readable than this
(https://github.com/macports/macports-ports/blob/d2acce23fbd523073731b27505a879385674f290/php/php-swoole/Portfile#L16)
```
if {[vercmp ${php.branch} 7.1] >= 0} {
[...]
}
```
Or also proper, expressive, readable OOP. Like:
```
class Paraview(CMakePackage, CudaPackage):
"""ParaView is an open-source, multi-platform data analysis and
visualization application."""`
compared to the TCL version (that I don't even know if it would be
supported by Macports or not).
Or also a proper interactive debugger that could allow to step in
directly in the code and check the package manager status in that
right moment and speed up debugging instead of printing out things
around or reading the log after stopping the build in a specific
phase.
> Tcl is already as easy and flexible as anything, isn't it? What could you do
> in another language, that you would want to do in a portfile, that you can't
> do in Tcl?
Well, you can do lots of stuff also in x86_64 assembly too, probably
more than TCL, that does not mean it's an especially good fit for this
particular job or that it might exists better solutions w.r.t. certain
aspects today than TCL.
>
> > - Installing binary-only software.
>
> MacPorts already supports this and we have several ports doing this. It would
> be impossible for MacPorts to prevent portfiles from being able to do this
> since portfiles are Tcl files with the full facilities of the Tcl language
> available to them, so they can do anything.
I don't understand here, I'm not suggesting preventing installing
Re: Package managers and package versioning
On Oct 4, 2020, at 14:09, Jason Liu wrote: >> Where by "this" you again mean the ability to specify a previously-available >> version, not an arbitrary version that was never in a portfile. > > Yes, of course. If you look at the folder for the Blender package on the > Debian repo > > http://deb.debian.org/debian/pool/main/b/blender/ > > from my previous example, there are many versions of Blender that were > skipped. For instance, they skipped version 2.82 and went from 2.79b right to > 2.82a. And they skipped versions 2.83.0-2.83.4, and went from 2.82a right to > 2.83.5. Obviously, there would be no way for a user to try to install Blender > version 2.83.2 using apt-get, because that version was never packaged (i.e. > spec files don't exist) for that particular version of Blender. Let's try not to say "of course". Nothing is obvious in this discussion. Let us be very clear at every step what we are proposing so that we can have a meaningful discussion. It's my understanding, for example, that Homebrew allows the user to request to install the git master of a particular Homebrew formula, in effect allowing the user to (try to) install a version of the software that was never previously attempted by the formula's creator. This is what I was afraid was part of what was being proposed, and something I would not support adding to MacPorts. > The examples were meant to illustrate the fact that it's possible to restrict > the dependency versions when installing an old package. By specifying maximum > versions for all of a package's dependencies (by using something like <=2.4.0 > or <2.4.0), it would guarantee that the old package would never have to be > built against new dependencies, because if a user were to install the old > package, it would also install older versions of the dependencies. I understand that it would be possible to define a syntax for specifying dependency versions and that MacPorts base could be enhanced to parse it and even to find and download the right version of the portfile and to install different versions of ports to different locations. The problem is that if you are currently compatible with the latest version of a dependency, you do not know in advance whether you will be compatible with the next version of that dependency. So you can either be conservative or liberal. MacPorts has tended to be liberal in these matters, assuming that a port can build on any architecture, any OS version, with any compiler. Once it is discovered that it can't build on some subset of those, restrictions can be added. supported_archs can be used to rule out incompatible architectures. compiler.blacklist can be used to rule out incompatible compilers. Ports can indicate which OS versions they're compatible with, though not as elegantly as I would like. If we continue the liberal approach with dependencies, then we begin from the assumption that a port can use any version of a dependency. Let's say libpng declares it can use any version of zlib. Then years later zlib 2 is released and it is incompatible, breaking all versions of libpng we've published. There's now a lot of work to go edit each previous libpng to indicate that it requires zlib < 2. Alternatively, suppose we use the conservative approach and declare that libpng requires zlib < 2. Or zlib < 1.3. Or zlib < 1.2.12. We have no way to know in what future version of zlib, if any, incompatibility might arise. Suppose we declare compatibility with zlib < 2, and years later zlib 2 comes along and maintains perfect backward compatibility with zlib 1. Then our libpng would continue to use the old zlib 1, even though it would work with zlib 2, thus making users use outdated dependencies unnecessarily and possibly exposing them to bugs that have already been fixed in newer versions. And the solution then is to do a lot of work to go edit each previous libpng to update its zlib compatibility list. Either way, it's signing all port maintainers up for a lot of work. (Many port maintainers already don't do the currently expected amount of work to maintain their ports.) And all for the benefit of other ports being able to declare that they require an old version of libpng. We did have this problem once before, when some old ports were not compatible with libpng 1.4 when it came out. Rather than introducing a libpng12 compatibility port, we did the right thing and fixed other software to be compatible with libpng 1.4. If we had used a libpng12 port instead, we likely would never have noticed if and when those ports gained libpng 1.4 compatibility and would be forcing libpng12 on users unnecessarily for years to come. > This is one place where MacPort's activate/deactivate would really shine: If > someone wanted to install an old package, MacPorts would first deactivate all > of the dependencies that were too new, and then install the old versions of > the dependencies that are
waf.python configurable?
Hi all,
I’m working on mpv portfile but I couldn’t find a way to change {waf.python},
the python executable needed for waf. It’s currently failing to configure on
buildbots. In https://trac.macports.org/ticket/57927
the original maker of waf portgroup
said it is configurable. Anyone knows how?
Thanks,
Zhenfu
Re: How to abort a macports portfile on an error condition?
On Oct 3, 2020, at 05:42, Nils Breunese wrote: > 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. ui_error prints an error message. This is the primary means by which you should inform the user of the problem. Use sentences and use multiple ui_error statements if you need multiple lines. return -code error stops doing whatever MacPorts was doing at that point. Use this if you've determined that the port installation cannot continue. Usually both of these are used together. It also prints a short message if you provide one. Usually you should summarize what the problem was in two or three words such as "incompatible macOS version", known_fail yes currently does nothing other than add a value to that port's entry in the portindex stating that failure is expected. In the future MacPorts might use this information to, for example, skip unnecessary steps like installing a port's dependencies if the port is expected to fail. Currently, it is only used by our buildbot infrastructure to skip builds that are known to fail. You should only use known_fail yes if the criteria for the failure lines up with the criteria we use to generate different portindexes. We generate a different portindex for each os.platform/os.major/os.arch combination. So if your criteria for failure is that you cannot build on macOS 10.6 and earlier, great, use known_fail yes. If your criteria depends on the existence of particular files that may or may not be on everyone's system, or Xcode versions, or build architectures, or anything else, don't use known_fail yes.
Re: Supporting installing arbitrary port versions
On Oct 4, 2020, at 06:02, Ruben Di Battista wrote: > Is this something that really needs to be implemented from scratch? > There are other package managers that do this and are build to do this > (nix and spack come to mind). I don't know the difficulties of what > I'm going to propose, but wouldn't it be maybe easier to write a TCL > Lexer/Parser that allows to translate the TCL files to input files for > the other package managers and then tweak the `port` command to use > those package managers under the hoods? I'm a bit closer to spack > development, and they developed a concretizer > (https://archive.fosdem.org/2020/schedule/event/dependency_solving_not_just_sat/) > for the spec of the packages that took multiple years of work to be > finalized. So now you want MacPorts to become a wrapper around another system? That would be another colossal task, I don't know what the benefit of it would be, and it doesn't get us any closer to solving the previous colossal tasks I mentioned that stand in the way of being able to offer arbitrary versions and variants of all ports simultaneously, if that were something we wanted. > Personally I don't like the idea of shipping all package versions, > because there are already pieces of software developed for the same > reason and that, possibly, will do a better job than whatever Macports > will ever be able to do. ...then why are you suggesting the above? > For me the Macports scope must be kept > focused and small: installing (possibly latest versions of) > open-source stacks from source keeping compatibility with old systems > in the best way possible. There are already improvements that can be > done UX-wise keeping this same scope: two that come to (my) mind are: > - Using another DSL/Language for Portfile that is easier, more > flexible, and modern (e.g. Python) https://trac.macports.org/wiki/FAQ#whytcl explains why Tcl was chosen. For example, one benefit is the avoidance of a preponderance of symbols needed for basic tasks. In its most pure form, a portfile sets variables to values. In Tcl with the way that MacPorts has enhanced it, that can be accomplished in the simplest possible way: name zlib sets the variable "name" to the string "zlib". Can you do it that concisely in Python? Don't you instead have to write: name='zlib' Isn't that going to get old really quickly when you have to set a dozen or more variables in each portfile? Tcl is already as easy and flexible as anything, isn't it? What could you do in another language, that you would want to do in a portfile, that you can't do in Tcl? > - Installing binary-only software. MacPorts already supports this and we have several ports doing this. It would be impossible for MacPorts to prevent portfiles from being able to do this since portfiles are Tcl files with the full facilities of the Tcl language available to them, so they can do anything.
Re: Package managers and package versioning
> > Where by "this" you again mean the ability to specify a > previously-available version, not an arbitrary version that was never in a > portfile. > Yes, of course. If you look at the folder for the Blender package on the Debian repo http://deb.debian.org/debian/pool/main/b/blender/ from my previous example, there are many versions of Blender that were skipped. For instance, they skipped version 2.82 and went from 2.79b right to 2.82a. And they skipped versions 2.83.0-2.83.4, and went from 2.82a right to 2.83.5. Obviously, there would be no way for a user to try to install Blender version 2.83.2 using apt-get, because that version was never packaged (i.e. spec files don't exist) for that particular version of Blender. Those links again do not explain how to overcome the challenges of building > an old portfile against new dependencies or on new operating systems or > compilers. > The examples were meant to illustrate the fact that it's possible to restrict the dependency versions when installing an old package. By specifying maximum versions for all of a package's dependencies (by using something like <=2.4.0 or <2.4.0), it would guarantee that the old package would never have to be built against new dependencies, because if a user were to install the old package, it would also install older versions of the dependencies. This is one place where MacPort's activate/deactivate would really shine: If someone wanted to install an old package, MacPorts would first deactivate all of the dependencies that were too new, and then install the old versions of the dependencies that are compatible with the old package. Despite the bloat it might work for that use case, but some npm module > developers unnecessarily restrict the versions of dependencies they're > compatible with, meaning that you get an unnecessarily outdated version of > that dependency, even though a newer version of the dependency would work > and might fix some bug you're experiencing. And this ballooning of > dependencies can use a tremendously larger amount of disk space than if > just a single compatible copy of each dep had been installed. We already > have users complaining about unnecessary dependencies and unnecessary disk > usage; this would just make it worse. > > And do you really want to install a separate copy of gettext for each > dependency that uses it? > Well, let's be frank here. This is the "Apple way". Other than the system frameworks, Apple has always strongly encouraged that software keep all of its bits and pieces inside of its application bundle in the /Applications folder. This has traditionally meant that multiple apps would have their own copy of the same gettext library in each of their application bundles; because Apple has never said "hey developers, put all of your shared libraries in this /usr/local or /opt/local folder". Instead, they've always gone the route of "each and every app only gets to play in its own sandbox; you should bring all of your own toys (i.e. libraries) to your own sandbox... no sharing of toys! (other than the ones Apple provides and controls, i.e. system frameworks)" I'm not saying that I agree with Apple's viewpoint, but I do find it a bit odd that users would use a *nix-like argument of "share as much as possible to reduce bloat" to complain about something (MacPorts) that lives on an Apple Corporation-made system, where "share as little as possible" is the norm. MacPorts is already a shining example of sharing and reusing the same libraries on a system that highly discourages such behavior. 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. > How would you address the "implicit declaration of function" problem I > mentioned? A new version of Xcode, 12, has come along and shown us that a > zillion of our ports, such as php, do not include the headers that declare > the functions they are using. We must fix this for compatibility with > future Macs. > > This is just an example of the type of problem that comes up all the time. > Yosemite required tons of patches because many build systems misinterpreted > 10.10 as 10.1. macOS 11 is requiring tons of patches because many build > systems expected the macOS major version to remain at 10 forever. Many > build systems need patches now for ARM support. etc. etc. etc. > In this particular case, I believe that the Xcode version, and even the macOS version, should be counted as just another type of dependency... one that happens to be required in every single portfile. If these (required) variables also had the ability to specify version ranges, we could effectively cap each version of a portfile with a maximum compatible
Re: Supporting installing arbitrary port versions
This is a Terrible Idea. The first rule of computer security is to update your stuff. Adding the complexity of allowing arbitrary software versions means that now we have to make sure that we update our stuff and make sure that we’re not still running old, insecure code even after we’ve updated. It’s asking for trouble. I don’t want Apple to give me the option of running old ssh (or any other old code) when I update macOS, and I don’t want MacPorts to give me the same option. And that’s on top of the unworkable maintenance issues discussed before. A big Nope, both as a user and a port maintainer. > On Oct 3, 2020, at 11:00 AM, Ryan Schmidt wrote: > > 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. smime.p7s Description: S/MIME cryptographic signature
Re: Supporting installing arbitrary port versions
Is this something that really needs to be implemented from scratch? There are other package managers that do this and are build to do this (nix and spack come to mind). I don't know the difficulties of what I'm going to propose, but wouldn't it be maybe easier to write a TCL Lexer/Parser that allows to translate the TCL files to input files for the other package managers and then tweak the `port` command to use those package managers under the hoods? I'm a bit closer to spack development, and they developed a concretizer (https://archive.fosdem.org/2020/schedule/event/dependency_solving_not_just_sat/) for the spec of the packages that took multiple years of work to be finalized. Personally I don't like the idea of shipping all package versions, because there are already pieces of software developed for the same reason and that, possibly, will do a better job than whatever Macports will ever be able to do. For me the Macports scope must be kept focused and small: installing (possibly latest versions of) open-source stacks from source keeping compatibility with old systems in the best way possible. There are already improvements that can be done UX-wise keeping this same scope: two that come to (my) mind are: - Using another DSL/Language for Portfile that is easier, more flexible, and modern (e.g. Python) - Installing binary-only software. just my 2¢ On Sun, Oct 4, 2020 at 7:58 AM Joshua Root wrote: > > 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 -- _ -. .´ | ', ;|∞∞ ˜˜ |∞ RdB ,.,|∞∞ .' '. | -' `' https://rdb.is
Re: Package managers and package versioning
> On Oct 3, 2020, at 20:23, Jason Liu wrote: > >> 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 Yup, once it has been shown how it would be possible to install multiple versions of a port simultaneously and request specific versions, it is obvious that dependencies would need to be able to specify versions. What specific syntax would be used to do that isn't important at this point. >> 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 Where by "this" you again mean the ability to specify a previously-available version, not an arbitrary version that was never in a portfile. Those links again do not explain how to overcome the challenges of building an old portfile against new dependencies or on new operating systems or compilers. > NPM and Yarn, which are PMSes for JavaScript packages, were created with > package versioning capabilities as a feature right from their very beginnings: npm is one I'm familiar with from an attempt to redesign the MacPorts web site several years ago. Its intended use is that you install the modules that are needed for your web site project. Each of your projects has its own node_modules directory and its own copy of every module. Not only that, but each module that you install with npm might have its own dependencies which get installed in yet another node_modules directory. This can quickly balloon out of control as you get 25 different versions of the same dependency. Despite the bloat it might work for that use case, but some npm module developers unnecessarily restrict the versions of dependencies they're compatible with, meaning that you get an unnecessarily outdated version of that dependency, even though a newer version of the dependency would work and might fix some bug you're experiencing. And this ballooning of dependencies can use a tremendously larger amount of disk space than if just a single compatible copy of each dep had been installed. We already have users complaining about unnecessary dependencies and unnecessary disk usage; this would just make it worse. Specifying what versions of dependencies are compatible might work in npm
