Re: UPDATE: bsd.port.mk - Add GitLab support
On 2019/01/02 11:59, Charles A Daniels wrote: > > The alternative is to mirror stable distfiles. > > Mirror them where? Someone will have to pony up the developer time and > infrastructure (hardware, disk space, bandwidth) to make that happen at > any kind of scale. Wherever is convenient for that person. Could even be hosted on github ;-) That hasn't proven itself to be a problem thus far, many software projects do have a proper release generation process. If it becomes more widely needed then maybe it would be worth having some infrastructure to generate and host tars from git repos centrally ourselves. (I think that needs doing at port creation/update time, the fetches done on build machines are deliberately very simple - the amount of code with network access privileges on those machines is very limited). That could also take care of the things like submodules which these simple cgi frontends to git-archive don't handle. > > Those are simply to make the URLs and directory names easier to work with > > and don't do anything to increase distfile stability. > > I am aware. The point I was getting at, which in retrospect I didn't > explain very clearly, is that this appears something that the GitLab > folks care about to some extent. Raising the issue with them might be > worthwhile. Given that these can be needed for *any* commit not even just tags, generating on the fly is really the only sane way from their point of view. > > Github at least has uploadable release assets which allow projects to > > provide stable distfiles without looking for alternative hosting. > > (And guess what, that doesn't use the GH_* support because it's just > > a simple download and most upstreams have sensible directory names > > etc). The best you can do with Gitlab is the dirty hack of committing > > distfiles themselves to a repo. > > I believe the public GitLab instance also has a GitHub-Pages work- > alike. In principle one could have CI script to upload release > artifacts there. That's a pretty gross solution though. > > > On-the-fly tarball generation is simply not compatible with checking > > distfile hashes to ensure that the downloaded files are not corrupted > > or backdoored. > > Admittedly I'm not deeply familiar with the tar binary format, but I > don't see why GitHub (et al.) couldn't make on-the-fly generation > produce tarballs with consistent hashes if they wanted to. Taking the > same set of files and generating a tar with them multiple times aught > to produce the same binary as a result no? This doesn't prevent the > upstreams from misbehaving by rebasing over an existing tag, but then > again they could also delete and re-upload an artifact with the same > name - in either case that *should* cause a checksum failure. It's not (usually) a "changes every time" thing (as long as creation timestamps are set to something that doesn't move around - though that has been a problem in the past). But changes to git, the tar program, the compression program, can all result in a different produced file. And of course changes to give nicer directory names as above would do the same! These can either be changed over time, or different versions can be present at the same time on different nodes around the world - in which case the files would be fetchable for some people but not others (we've seen this with github files).
Re: UPDATE: bsd.port.mk - Add GitLab support
On Wed, Jan 02, 2019 at 11:59:51AM -0500, Charles A Daniels wrote: [...] > > If that happens and the distfiles prove unstable we will need to do > > *something* though .. and we won't be the only ones, any packagers that > > check distfiles (either by hashes or by pgp signatures as is more common > > on Linux) will need stable files to do that. > > What doe the Debian guys do? I know they are pretty big on re- > producible builds. I was not able to figure out how they validate the > distfiles from the about page for the re-producible builds initiative. > Maybe we could reach out to the Debian mailing list about this - they > surely have the same problem and have either solved it, or are working > on solving it. Debian doesn't fetch from external sources. The developer generates a tarball from the program source and upload it to their servers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: bsd.port.mk - Add GitLab support
Marc, > I would very much be in favor of people providing hosting services where this > does not exist, and to have an actual FAQ of things to tell upstream so that > they prepare actual properly tagged releases on platforms such as github. I think an FAQ page to explain to porters whats going on and what to do would be good, in addition to an FAQ page to link to upstream explaining to them why it is important and how they can proceed. I have some experience with technical writing, and would be willing to spend some time writing these pages. If that sounds good to you or someone else here, reach out to me via email and we can discuss in more detail. I'm also unfamiliar with the process for contributing to the FAQ; is there an FAQ about updating the FAQ? - Antoine, > I'm slightly worried because each time we add pieces to bsd.port.mk, it > becomes slightly harder to mainain. > > > > Just, if things break later (bad checksums, dpb support needed), I expect > some help! > > Specifically, if we end up requiring extra support for fetch-time dependencies > to create verifiable tarballs or whatever, don't expect me to do the > heavy-weight pulling. I agree that adding a bunch of extra dependencies just to be able to fetch ports is not ideal. > If that happens and the distfiles prove unstable we will need to do > *something* though .. and we won't be the only ones, any packagers that > check distfiles (either by hashes or by pgp signatures as is more common > on Linux) will need stable files to do that. What doe the Debian guys do? I know they are pretty big on re- producible builds. I was not able to figure out how they validate the distfiles from the about page for the re-producible builds initiative. Maybe we could reach out to the Debian mailing list about this - they surely have the same problem and have either solved it, or are working on solving it. - Stuart, > > At a certain point, we either need to start mirroring all of these > > releases somewhere, or find a solution to work around the problems of > > this style of software release. > The alternative is to mirror stable distfiles. Mirror them where? Someone will have to pony up the developer time and infrastructure (hardware, disk space, bandwidth) to make that happen at any kind of scale. > Those are simply to make the URLs and directory names easier to work with > and don't do anything to increase distfile stability. I am aware. The point I was getting at, which in retrospect I didn't explain very clearly, is that this appears something that the GitLab folks care about to some extent. Raising the issue with them might be worthwhile. > Github at least has uploadable release assets which allow projects to > provide stable distfiles without looking for alternative hosting. > (And guess what, that doesn't use the GH_* support because it's just > a simple download and most upstreams have sensible directory names > etc). The best you can do with Gitlab is the dirty hack of committing > distfiles themselves to a repo. I believe the public GitLab instance also has a GitHub-Pages work- alike. In principle one could have CI script to upload release artifacts there. That's a pretty gross solution though. > On-the-fly tarball generation is simply not compatible with checking > distfile hashes to ensure that the downloaded files are not corrupted > or backdoored. Admittedly I'm not deeply familiar with the tar binary format, but I don't see why GitHub (et al.) couldn't make on-the-fly generation produce tarballs with consistent hashes if they wanted to. Taking the same set of files and generating a tar with them multiple times aught to produce the same binary as a result no? This doesn't prevent the upstreams from misbehaving by rebasing over an existing tag, but then again they could also delete and re-upload an artifact with the same name - in either case that *should* cause a checksum failure. ~ Charles
Re: UPDATE: bsd.port.mk - Add GitLab support
On 2018/12/31 19:01, Antoine Jacoutot wrote: > On Mon, Dec 31, 2018 at 05:45:19PM +0100, Marc Espie wrote: > > Adding more fluff to bsd.port.mk to support this style of code is fairly > > disturbing. > > > > I don't like the github stuff too much, it's somewhat error-prone and there > > is regular traffic on ports-changes proving it. > > > > Adding a SECOND source of problems does not seem like the way to go. > > > > There's also the issue of getting reliable checksum tarballs... especially > > if that ends up involving REQUIRING dependencies just to be able to fetch > > things. That's something we tried to avoid and that is definitely bug-prone. > > > > That will lead, at the least, to quality-issue problems. And possibly to > > actual security issues. > > > > On platforms where it is possible to have release tarballs that don't change > > I would say that's still a much better choice. > > > > I would very much be in favor of people providing hosting services where > > this > > does not exist, and to have an actual FAQ of things to tell upstream so that > > they prepare actual properly tagged releases on platforms such as github. > > That's what the GNOME project is currently doing (GitLab + some ftp space to > fetch tarballs). But if they end up changing and use generated tarballs from > GitLab directly, do not count on me to go see the 100+ different maintainers > of > the GNOME subprojects to ask them to change their policy. If that happens and the distfiles prove unstable we will need to do *something* though .. and we won't be the only ones, any packagers that check distfiles (either by hashes or by pgp signatures as is more common on Linux) will need stable files to do that. > I am in favor of having suppor for gitlab in bsd.port.mk. Lots of projects are > moving there and again it's very convenient because portroach would be able to > warn you when there are updates available (which could also be security > updates). FWIW PORTROACH=site: can still be used with mirrored distfiles if that's what we need to do ..
Re: UPDATE: bsd.port.mk - Add GitLab support
On 2018/12/31 11:28, Charles A Daniels wrote: > On Sun, 2018-12-30 at 23:57 +0100, Antoine Jacoutot wrote: > > On Sun, Dec 30, 2018 at 10:48:41PM +, Stuart Henderson wrote: > > > On 2018/12/29 15:44, Edward Lopez-Acosta wrote: > > > > Stuart, > > > > > > > > I am not sure I understand the question or the issues you refer to. Can > > > > you clarify for me so I can look more into it please? > > > > > > > > Are you also proposing the GitHub directives already provided are bad > > > > as well? > > > > > > > > On December 29, 2018 2:40:24 PM UTC, Stuart Henderson > > > > wrote: > > > > > On 2018/12/29 08:24, Edward Lopez-Acosta wrote: > > > > > > Any feedback for this? > > > > > > > > > > How is gitlab doing at keeping stable distfiles? If it's even worse > > > > > than > > > > > github (and I have a feeling it might be) then I wouldn't really want > > > > > to > > > > > encourage people using it directly as a source. > > > > > > See https://marc.info/?l=openbsd-ports=151973450514279=2 for more > > > about > > > the problem. > > For better or for worse, GitHub, Gitlab, Bitbucket, et. al. are the New > World Order of software development. I don't think not supporting > directives for these platforms is going to solve anything; the > alternative is just "don't package those things". The problem at hand > is the lack of proper releases from upstream. The alternative is to mirror stable distfiles. > I was just looking at porting Lollypop[1] since it looks neat and I > believe we have all the dependencies. Even the big guys like GNOME seem > to be using $GIT_FRONTEND_OF_CHOICE to handle their releases nowadays. > > At a certain point, we either need to start mirroring all of these > releases somewhere, or find a solution to work around the problems of > this style of software release. > > I don't have a good solution to offer up, but I would suggest that > keeping GitLab (or other git hosting platform) support out of > bsd.port.mk just shuffles the problem under the rug, and makes it > harder for people to write ports for software hosted there. > > I would further cite GitLab issue 38830[2] in support of merging > Edward's changes; this appears to be something that the GitLab folks > are aware of and have responded to in the past. In particular, GitLab > MR 17225[3] specifically adds support for `project-ref.ext` style > tarballs to support packaging. Those are simply to make the URLs and directory names easier to work with and don't do anything to increase distfile stability. Github at least has uploadable release assets which allow projects to provide stable distfiles without looking for alternative hosting. (And guess what, that doesn't use the GH_* support because it's just a simple download and most upstreams have sensible directory names etc). The best you can do with Gitlab is the dirty hack of committing distfiles themselves to a repo. > Perhaps it would be constructive to reach out to the GitLab development > team directly to see if their archive generations and handling is > compatible with the requirements of the OpenBSD ports tree? On-the-fly tarball generation is simply not compatible with checking distfile hashes to ensure that the downloaded files are not corrupted or backdoored. > ~ Charles > > 1 - https://wiki.gnome.org/Apps/Lollypop > 2 - https://gitlab.com/gitlab-org/gitlab-ce/issues/38830 > 3 - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17225 >
Re: UPDATE: bsd.port.mk - Add GitLab support
On Mon, Dec 31, 2018 at 07:01:16PM +0100, Antoine Jacoutot wrote: > On Mon, Dec 31, 2018 at 05:45:19PM +0100, Marc Espie wrote: > > Adding more fluff to bsd.port.mk to support this style of code is fairly > > disturbing. > > > > I don't like the github stuff too much, it's somewhat error-prone and there > > is regular traffic on ports-changes proving it. > > > > Adding a SECOND source of problems does not seem like the way to go. > > > > There's also the issue of getting reliable checksum tarballs... especially > > if that ends up involving REQUIRING dependencies just to be able to fetch > > things. That's something we tried to avoid and that is definitely bug-prone. > > > > That will lead, at the least, to quality-issue problems. And possibly to > > actual security issues. > > > > On platforms where it is possible to have release tarballs that don't change > > I would say that's still a much better choice. > > > > I would very much be in favor of people providing hosting services where > > this > > does not exist, and to have an actual FAQ of things to tell upstream so that > > they prepare actual properly tagged releases on platforms such as github. > > That's what the GNOME project is currently doing (GitLab + some ftp space to > fetch tarballs). But if they end up changing and use generated tarballs from > GitLab directly, do not count on me to go see the 100+ different maintainers > of > the GNOME subprojects to ask them to change their policy. > > I am in favor of having suppor for gitlab in bsd.port.mk. Lots of projects are > moving there and again it's very convenient because portroach would be able to > warn you when there are updates available (which could also be security > updates). Oh, the gitlab part itself would be fine. Though it is very incomplete, as it also needs - some documentation in bsd.port.mk(5) - some more fluff in sqlports I'd first like an actually complete patch with all the pieces. I'm slightly worried because each time we add pieces to bsd.port.mk, it becomes slightly harder to mainain. Just, if things break later (bad checksums, dpb support needed), I expect some help! Specifically, if we end up requiring extra support for fetch-time dependencies to create verifiable tarballs or whatever, don't expect me to do the heavy-weight pulling.
Re: UPDATE: bsd.port.mk - Add GitLab support
On Mon, Dec 31, 2018 at 05:45:19PM +0100, Marc Espie wrote: > Adding more fluff to bsd.port.mk to support this style of code is fairly > disturbing. > > I don't like the github stuff too much, it's somewhat error-prone and there > is regular traffic on ports-changes proving it. > > Adding a SECOND source of problems does not seem like the way to go. > > There's also the issue of getting reliable checksum tarballs... especially > if that ends up involving REQUIRING dependencies just to be able to fetch > things. That's something we tried to avoid and that is definitely bug-prone. > > That will lead, at the least, to quality-issue problems. And possibly to > actual security issues. > > On platforms where it is possible to have release tarballs that don't change > I would say that's still a much better choice. > > I would very much be in favor of people providing hosting services where this > does not exist, and to have an actual FAQ of things to tell upstream so that > they prepare actual properly tagged releases on platforms such as github. That's what the GNOME project is currently doing (GitLab + some ftp space to fetch tarballs). But if they end up changing and use generated tarballs from GitLab directly, do not count on me to go see the 100+ different maintainers of the GNOME subprojects to ask them to change their policy. I am in favor of having suppor for gitlab in bsd.port.mk. Lots of projects are moving there and again it's very convenient because portroach would be able to warn you when there are updates available (which could also be security updates). -- Antoine
Re: UPDATE: bsd.port.mk - Add GitLab support
Adding more fluff to bsd.port.mk to support this style of code is fairly disturbing. I don't like the github stuff too much, it's somewhat error-prone and there is regular traffic on ports-changes proving it. Adding a SECOND source of problems does not seem like the way to go. There's also the issue of getting reliable checksum tarballs... especially if that ends up involving REQUIRING dependencies just to be able to fetch things. That's something we tried to avoid and that is definitely bug-prone. That will lead, at the least, to quality-issue problems. And possibly to actual security issues. On platforms where it is possible to have release tarballs that don't change I would say that's still a much better choice. I would very much be in favor of people providing hosting services where this does not exist, and to have an actual FAQ of things to tell upstream so that they prepare actual properly tagged releases on platforms such as github.
Re: UPDATE: bsd.port.mk - Add GitLab support
On Sun, 2018-12-30 at 23:57 +0100, Antoine Jacoutot wrote: > On Sun, Dec 30, 2018 at 10:48:41PM +, Stuart Henderson wrote: > > On 2018/12/29 15:44, Edward Lopez-Acosta wrote: > > > Stuart, > > > > > > I am not sure I understand the question or the issues you refer to. Can > > > you clarify for me so I can look more into it please? > > > > > > Are you also proposing the GitHub directives already provided are bad as > > > well? > > > > > > On December 29, 2018 2:40:24 PM UTC, Stuart Henderson > > > wrote: > > > > On 2018/12/29 08:24, Edward Lopez-Acosta wrote: > > > > > Any feedback for this? > > > > > > > > How is gitlab doing at keeping stable distfiles? If it's even worse > > > > than > > > > github (and I have a feeling it might be) then I wouldn't really want > > > > to > > > > encourage people using it directly as a source. > > > > See https://marc.info/?l=openbsd-ports=151973450514279=2 for more about > > the problem. For better or for worse, GitHub, Gitlab, Bitbucket, et. al. are the New World Order of software development. I don't think not supporting directives for these platforms is going to solve anything; the alternative is just "don't package those things". The problem at hand is the lack of proper releases from upstream. I was just looking at porting Lollypop[1] since it looks neat and I believe we have all the dependencies. Even the big guys like GNOME seem to be using $GIT_FRONTEND_OF_CHOICE to handle their releases nowadays. At a certain point, we either need to start mirroring all of these releases somewhere, or find a solution to work around the problems of this style of software release. I don't have a good solution to offer up, but I would suggest that keeping GitLab (or other git hosting platform) support out of bsd.port.mk just shuffles the problem under the rug, and makes it harder for people to write ports for software hosted there. I would further cite GitLab issue 38830[2] in support of merging Edward's changes; this appears to be something that the GitLab folks are aware of and have responded to in the past. In particular, GitLab MR 17225[3] specifically adds support for `project-ref.ext` style tarballs to support packaging. Perhaps it would be constructive to reach out to the GitLab development team directly to see if their archive generations and handling is compatible with the requirements of the OpenBSD ports tree? ~ Charles 1 - https://wiki.gnome.org/Apps/Lollypop 2 - https://gitlab.com/gitlab-org/gitlab-ce/issues/38830 3 - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17225
Re: UPDATE: bsd.port.mk - Add GitLab support
On Sun, Dec 30, 2018 at 10:48:41PM +, Stuart Henderson wrote: > On 2018/12/29 15:44, Edward Lopez-Acosta wrote: > > Stuart, > > > > I am not sure I understand the question or the issues you refer to. Can you > > clarify for me so I can look more into it please? > > > > Are you also proposing the GitHub directives already provided are bad as > > well? > > > > On December 29, 2018 2:40:24 PM UTC, Stuart Henderson > > wrote: > > >On 2018/12/29 08:24, Edward Lopez-Acosta wrote: > > >> Any feedback for this? > > > > > >How is gitlab doing at keeping stable distfiles? If it's even worse > > >than > > >github (and I have a feeling it might be) then I wouldn't really want > > >to > > >encourage people using it directly as a source. > > > > See https://marc.info/?l=openbsd-ports=151973450514279=2 for more about > the problem. I agree the situation is far from nice when using on-demand generated tarballs. But, it's really handy for portroach, so we know when there's an update available. -- Antoine
Re: UPDATE: bsd.port.mk - Add GitLab support
On 2018/12/29 15:44, Edward Lopez-Acosta wrote: > Stuart, > > I am not sure I understand the question or the issues you refer to. Can you > clarify for me so I can look more into it please? > > Are you also proposing the GitHub directives already provided are bad as well? > > On December 29, 2018 2:40:24 PM UTC, Stuart Henderson > wrote: > >On 2018/12/29 08:24, Edward Lopez-Acosta wrote: > >> Any feedback for this? > > > >How is gitlab doing at keeping stable distfiles? If it's even worse > >than > >github (and I have a feeling it might be) then I wouldn't really want > >to > >encourage people using it directly as a source. > See https://marc.info/?l=openbsd-ports=151973450514279=2 for more about the problem.
Re: UPDATE: bsd.port.mk - Add GitLab support
Stuart, I am not sure I understand the question or the issues you refer to. Can you clarify for me so I can look more into it please? Are you also proposing the GitHub directives already provided are bad as well? On December 29, 2018 2:40:24 PM UTC, Stuart Henderson wrote: >On 2018/12/29 08:24, Edward Lopez-Acosta wrote: >> Any feedback for this? > >How is gitlab doing at keeping stable distfiles? If it's even worse >than >github (and I have a feeling it might be) then I wouldn't really want >to >encourage people using it directly as a source.
Re: UPDATE: bsd.port.mk - Add GitLab support
On 2018/12/29 08:24, Edward Lopez-Acosta wrote: > Any feedback for this? How is gitlab doing at keeping stable distfiles? If it's even worse than github (and I have a feeling it might be) then I wouldn't really want to encourage people using it directly as a source.
Re: UPDATE: bsd.port.mk - Add GitLab support
Any feedback for this?
Edward Lopez-Acosta
On 12/16/18 9:11 AM, Edward Lopez-Acosta wrote:
Hello,
I spent some time and added GitLab support to bsd.port.mk in a similar
manner as GitHub. Since Microsoft's acquisition of GitHub a large number
of projects, including major ones like the freedesktop project, have
migrated to GitLab. I also have a number of projects at GitLab that I
have been thinking of porting.
https://about.gitlab.com/2018/06/03/movingtogitlab/
https://about.gitlab.com/2018/08/20/freedesktop-org-migrates-to-gitlab/
I did some tests on this and it seems to work like the GH_* directives
but would like some additional review if possible please.
Thank you,
diff --git bsd.port.mk bsd.port.mk
index a31757c39fc..ef76d864c8e 100644
--- bsd.port.mk
+++ bsd.port.mk
@@ -129,6 +129,7 @@ _ALL_VARIABLES += HOMEPAGE DISTNAME \
SHARED_LIBS TARGETS PSEUDO_FLAVOR \
MAINTAINER AUTOCONF_VERSION AUTOMAKE_VERSION CONFIGURE_ARGS \
GH_ACCOUNT GH_COMMIT GH_PROJECT GH_TAGNAME PORTROACH \
+ GL_ACCOUNT GL_COMMIT GL_PROJECT GL_TAGNAME \
PORTROACH_COMMENT MAKEFILE_LIST USE_LLD USE_WXNEEDED COMPILER \
COMPILER_LANGS COMPILER_LINKS SUBST_VARS UPDATE_PLIST_ARGS \
PKGPATHS
@@ -620,6 +621,15 @@ GH_PROJECT ?=
DISTNAME ?= ${GH_PROJECT}-${GH_TAGNAME:C/^v//}
.endif
+GL_TAGNAME ?=
+GL_COMMIT ?=
+GL_ACCOUNT ?=
+GL_PROJECT ?=
+
+.if !empty(GL_PROJECT) && !empty(GL_TAGNAME)
+DISTNAME ?= ${GL_PROJECT}-${GL_TAGNAME:C/^v//}
+.endif
+
PKGNAME ?= ${DISTNAME}
FULLPKGNAME ?= ${PKGNAME}${FLAVOR_EXT}
_MASTER ?=
@@ -868,6 +878,18 @@ WRKDIST ?= ${WRKDIR}/${DISTNAME}
. endif
.endif
+.if !empty(GL_TAGNAME)
+WRKDIST ?= ${WRKDIR}/${GL_PROJECT}-${GL_TAGNAME:C/^v//}
+.elif !empty(GL_COMMIT)
+WRKDIST ?= ${WRKDIR}/${GL_PROJECT}-${GL_COMMIT}
+.else
+. if !defined(DISTNAME)
+WRKDIST ?= ${WRKDIR}
+. else
+WRKDIST ?= ${WRKDIR}/${DISTNAME}
+. endif
+.endif
+
WRKSRC ?= ${WRKDIST}
.if ${SEPARATE_BUILD:L} != "no"
@@ -1184,6 +1206,28 @@ HOMEPAGE ?= https://github.com/${GH_ACCOUNT}/${GH_PROJECT}
MASTER_SITES ?=
.endif
+.if !empty(GL_ACCOUNT) && !empty(GL_PROJECT)
+. if !empty(GL_COMMIT) && !empty(GL_TAGNAME)
+ERRORS += "Fatal: specifying both GL_TAGNAME and GL_COMMIT is invalid"
+. endif
+. if ${GL_TAGNAME} == master
+ERRORS += "Fatal: using master as GL_TAGNAME is invalid"
+. endif
+. if !empty(GL_TAGNAME)
+MASTER_SITES_GITLAB += \
+ https://gitlab.com/${GL_ACCOUNT}/${GL_PROJECT}/-/archive/${GL_TAGNAME:S/$/\//}
+. else
+MASTER_SITES_GITLAB += \
+ https://gitlab.com/${GL_ACCOUNT}/${GL_PROJECT}/-/archive/${GL_COMMIT}/${GL_PROJECT-}${GL_COMMIT:S/$/\//}
+. endif
+
+MASTER_SITES ?= ${MASTER_SITES_GITLAB}
+HOMEPAGE ?= https://gitlab.com/${GL_ACCOUNT}/${GL_PROJECT}
+.else
+# Empty declarations to avoid "variable XXX is recursive" errors
+MASTER_SITES ?=
+.endif
+
# I guess we're in the master distribution business! :) As we gain mirror
# sites for distfiles, add them to MASTER_SITE_BACKUP
@@ -1211,6 +1255,14 @@ DISTFILES ?= ${DISTNAME}${EXTRACT_SUFX}
. endif
.endif
+.if !empty(GL_COMMIT)
+DISTFILES ?= ${DISTNAME}-${GL_COMMIT:C/().*/\1/}${EXTRACT_SUFX}{${GL_COMMIT}${EXTRACT_SUFX}}
+.else
+. if defined(DISTNAME)
+DISTFILES ?= ${DISTNAME}${EXTRACT_SUFX}
+. endif
+.endif
+
PATCHFILES ?=
SUPDISTFILES ?=
