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 +0000, 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 > > > > <[email protected]> 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&m=151973450514279&w=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 >
