Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On May 22, 2022, at 5:32 AM, Ryan Schmidt wrote: > It is possible but not permitted to specify "the latest code" (such as a > Subversion repository trunk or a git repository main or master branch or the > head of any branch in any revision control system in fact) because if you did > that, what one user received when they installed the port at one moment in > time would be different from what another user received if they installed it > at a different moment in time if there had been commits to that branch of the > repository between those two moments in time, but MacPorts would not convey > that difference in the output of "port installed", nor would "port outdated" > convey to the user who installed the port first that any update were > available. If the port is distributable, users would receive even older > versions of the software from whenever the buildbot first built it. +1 for this We'd not want such a port in the man repository, but in Bill's case, it would be reasonable for him to do this locally... Macports wouldn't know that the trunk (or whatever branch) had been updated, so he'd need to manually rebuild - but that seems like something manageable for just using MacPorts for nice reproducible(ish) builds + easy cleanup of temporary versions. -- Daniel J. Luke
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
You can (for yourself) just change the github commit to HEAD and you’ll get the latest commit. Disable the checksum phase if you do that. I often do that in some of my local portfile overlay repos for my own uses, but you can’t do that for macports in general as Ryan points out as the builds are not reproducible. K
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On May 21, 2022, at 10:22, Bill Cole wrote: > I'm currently working on a OSS project (SpamAssassin) which is in a > pre-release rush and which I ultimately test & deploy via MacPorts. > > I'd *like* to be able to switch from the current supported release in > MacPorts to a fresh build from a Subversion checkout without manually > mimicking what MP does (in part because I'm not 100% confident that I am > doing it right) so that I can do testing iteration in a more efficient and > repeatable fashion. This would be a different level of 'reckless cowboy' > beyond the '-devel' ports we already have here and there with prerelease > software. > > I expect that this does not exist (I can't find anything...) but that it > could. MP would need to always do a fetch/checkout/update/pull from the > source control repo (I presume it would need BOTH svn and git support) and > require use of a secure transport to make trusting the code without tarball > checksums reasonable. > > Does anyone else like the idea of this? See a need? Hate it? Already have a > private tool for this? MacPorts already supports fetching from most revision control systems including Subversion and git. Using this feature is discouraged but is possible. See https://guide.macports.org/chunked/reference.phases.html#reference.phases.fetch The port must be written so that a specific revision or commit hash or tag from the revision control system is fetched. If upstream makes new commits and it is desired for the port to install that newly revised code, the portfile should be updated to reflect that, each time. It is possible but not permitted to specify "the latest code" (such as a Subversion repository trunk or a git repository main or master branch or the head of any branch in any revision control system in fact) because if you did that, what one user received when they installed the port at one moment in time would be different from what another user received if they installed it at a different moment in time if there had been commits to that branch of the repository between those two moments in time, but MacPorts would not convey that difference in the output of "port installed", nor would "port outdated" convey to the user who installed the port first that any update were available. If the port is distributable, users would receive even older versions of the software from whenever the buildbot first built it. Enhancing MacPorts to support some new notion of a port's outdatedness that would include network communication to a third-party revision control system has not been planned. It does not seem like a good idea to me. A fundamental concept in MacPorts is that a user has the assurance that at least one human has verified that a port builds successfully. Allowing the user access to arbitrary never-before-tested versions of the software is contrary to that.
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On 2022-05-21 at 20:23:49 UTC-0400 (Sat, 21 May 2022 20:23:49 -0400) Andrew Udvare is rumored to have said: If it's off GitHub or GitLab you don't have to create the tarball unless it has submodules (you can also fetch multiple tarballs but this is complex). In this case (and for many ASF projects) the master version control is Subversion, so the only way I'm getting a tarball is making it client-side. I actually have a script to update my ports that are of 'latest version' tarballs. https://github.com/Tatsh/ports/blob/master/_resources/bin/liveupdate That could be useful, thanks. Unfortunately on MacPorts there's no PortGroup to use git or similar to fetch the latest code. I guess it's because it will almost certainly bring more tickets into the system Understood. I see this mostly as a developers tool, with explicit non-support. especially when said latest versions are important dependencies. On Gentoo we do have this feature (provided by eclasses, equivalent of PoetGroup) and you have to make configuration changes to use it when it comes to packages in the main tree. This makes the point that you're on your own when you start doing this to your system. You can write your own PortGroup to do this so the code can be shared among your ports, similar to Gentoo's way: https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/git-r3.eclass Basically, git clone if the clone isn't there already, update otherwise (replacing fetch phase). Don't forget submodules. Make the clone live somewhere permanent until the package is uninstalled. When installing, copy recursively the clone to the normal build directory (replacing the extract phase) then the rest of the system can work as is. Food for thought. Thanks. On Sat, May 21, 2022, 16:38 Bill Cole < macportsusers-20171...@billmail.scconsult.com> wrote: On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400) Andrew Udvare is rumored to have said: Rather than pull via version control, Which is MY GOAL, not an incidental mechanical issue. grab a tarball with the SHA you want. Which would mean creating an ad hoc tarball before each (rapid) update. That's how I do 'latest' version ports. Well, that requires: 1. creating a tarball 2. calculating the hashes 3. editing the portfile Which is a lot of fiddling for each new version. My goal is to NOT do all that, but to get the same installation that I would get if I did. It is also to have a way that non-developer users can easily install the actual latest version of the moment, which is sometimes the easiest way to get fixes that don't merit a full release. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
If it's off GitHub or GitLab you don't have to create the tarball unless it has submodules (you can also fetch multiple tarballs but this is complex). I actually have a script to update my ports that are of 'latest version' tarballs. https://github.com/Tatsh/ports/blob/master/_resources/bin/liveupdate Unfortunately on MacPorts there's no PortGroup to use git or similar to fetch the latest code. I guess it's because it will almost certainly bring more tickets into the system especially when said latest versions are important dependencies. On Gentoo we do have this feature (provided by eclasses, equivalent of PoetGroup) and you have to make configuration changes to use it when it comes to packages in the main tree. This makes the point that you're on your own when you start doing this to your system. You can write your own PortGroup to do this so the code can be shared among your ports, similar to Gentoo's way: https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/git-r3.eclass Basically, git clone if the clone isn't there already, update otherwise (replacing fetch phase). Don't forget submodules. Make the clone live somewhere permanent until the package is uninstalled. When installing, copy recursively the clone to the normal build directory (replacing the extract phase) then the rest of the system can work as is. On Sat, May 21, 2022, 16:38 Bill Cole < macportsusers-20171...@billmail.scconsult.com> wrote: > On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400) > Andrew Udvare > is rumored to have said: > > > Rather than pull via version control, > > Which is MY GOAL, not an incidental mechanical issue. > > > grab a tarball with the SHA you want. > > Which would mean creating an ad hoc tarball before each (rapid) update. > > > That's how I do 'latest' version ports. > > Well, that requires: > > 1. creating a tarball > 2. calculating the hashes > 3. editing the portfile > > Which is a lot of fiddling for each new version. > My goal is to NOT do all that, but to get the same installation that I > would get if I did. It is also to have a way that non-developer users can > easily install the actual latest version of the moment, which is sometimes > the easiest way to get fixes that don't merit a full release. > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire >
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400) Andrew Udvare is rumored to have said: > Rather than pull via version control, Which is MY GOAL, not an incidental mechanical issue. > grab a tarball with the SHA you want. Which would mean creating an ad hoc tarball before each (rapid) update. > That's how I do 'latest' version ports. Well, that requires: 1. creating a tarball 2. calculating the hashes 3. editing the portfile Which is a lot of fiddling for each new version. My goal is to NOT do all that, but to get the same installation that I would get if I did. It is also to have a way that non-developer users can easily install the actual latest version of the moment, which is sometimes the easiest way to get fixes that don't merit a full release. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
Rather than pull via version control, grab a tarball with the SHA you want. That's how I do 'latest' version ports. On Sat, May 21, 2022, 11:23 Bill Cole < macportsusers-20171...@billmail.scconsult.com> wrote: > I'm currently working on a OSS project (SpamAssassin) which is in a > pre-release rush and which I ultimately test & deploy via MacPorts. > > I'd *like* to be able to switch from the current supported release in > MacPorts to a fresh build from a Subversion checkout without manually > mimicking what MP does (in part because I'm not 100% confident that I am > doing it right) so that I can do testing iteration in a more efficient and > repeatable fashion. This would be a different level of 'reckless cowboy' > beyond the '-devel' ports we already have here and there with prerelease > software. > > I expect that this does not exist (I can't find anything...) but that it > could. MP would need to always do a fetch/checkout/update/pull from the > source control repo (I presume it would need BOTH svn and git support) and > require use of a secure transport to make trusting the code without tarball > checksums reasonable. > > Does anyone else like the idea of this? See a need? Hate it? Already have > a private tool for this? > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire >
