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.
