Setting up a new BSP today, and I'm again disappointed to find that it contains recipes that specify `protocol=git`: ``` $ grep -rlI "protocol=git" * recipes-bsp/u-boot/u-boot-common.inc recipes-kernel/linux-firmware/linux-firmware_git.bbappend recipes-kernel/linux/linux-variscite_4.14.78.bb ``` I'm behind a strict corporate HTTP proxy and can't use Git protocol, so I always have to play several rounds of 'whack-a-mole' to fix these problematic recipes using, e.g., clever `PREMIRRORS_prepend` gymnastics and/or append recipes. This is a complete waste of time, for me and every other Bitbake user behind a strict HTTP proxy. Nowadays, Git's [Smart HTTP procotol][1] means there's little benefit in Bitbake continuing to support Git protocol. It's not needed[2], and leaving it in place causes real pain for a whole lot of people toiling away in large corporations. As long as Bitbake permits Git protocol to be specified, people will continue authoring recipes that use it, causing a raft of problems for strangers like me they'll probably never meet. It's unrealistic to think that "the community" can police itself in this matter. They won't. Bitbake can save everybody a lot of hassle[3] by deprecating Git protocol, issuing warnings for its use for the next couple of years, and then removing it entirely. [1]: https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP [2]: I suspect that Git protocol is completely superfluous for 99.9% of Bitbake users: they literally couldn't care less whether a `SRC_URI` specifies `protocol=https` or `protocol=git`. But *using* Git protocol causes problems for—conservatively!—anywhere between 5% and 30% of users. Bitbake is optimizing for a 0.1% use case, at the expense of a *very* large number of users(!) [3]: It's not just the people behind HTTP proxies who are inconvenienced: vendors take a hit, too. Their support burden is increased due to customers having problems building their BSPs. And the issues are often with recipes that aren't even part of the vendor's layers, so they have to spend time educating their customers about this quirk of Bitbake, and explain how to work around it. Real money is being pissed away because of this, every single day.
I'm afraid I strongly disagree with your position here. Its perfectly reasonable for the project to use the git protocol and I suspect there are quite some number of http git servers which are not "smart". If we picked "http" as the default, people would complain it should be "https", some sites would support one and not to other and so on, we could never win anyway. What I do agree with is supporting http mirroring better, we should have an easy to use setting which would turn ;protocol=git into an attempt at protocol=http and protocol=https. There is an open bug for this. It may even nearly work today, I've just never had a chance to sit down and figure out the mirror url syntax or looked at what fixes may be needed to make that work. Help on such a patch would be very welcome over in that other bug.
> If we picked "http" as the default, people would complain it should be "https", some sites would support one and not to other and so on, we could never win anyway. Fair point, I hadn't even considered that there are people who still download source code using HTTP in the 21st century. To be clear, I was proposing that the default be `protocol=https`. (And yes, there would probably be some who would complain that it should be `protcol=http`, although... giving them much credence seems inadvisable.) > What I do agree with is supporting http mirroring better... > There is an open bug for this. Do you mean bug #3306? If so, LOL—I totally forgot I filed that! Funny that I'm still complaining about it *six years* later. If you can confirm that #3306 is the right bug, I'll try to prepare a patch. Feel free to close this bug if you think it's the wrong way to address the issue. In hindsight, it does seem like an attempt to put a Band-Aid on a larger, more general issue, namely: Bitbake's defaults aren't "opinionated" enough to allow non-experts to write recipes that won't cause problems for some (possibly *large*) subset of their intended audience. Bitbake allows me to do all sorts of things that I learn only later are A Bad Idea™. Sometimes, I wish it would stop me, but... perhaps a linter for recipes (see bug #13206) is a better solution.
We have discussions in three related bugs here. Basically rather than update the metadata to fit some particiular firewall config or set of circumstances, I'd prefer to do this through our mirrors syntax. There may be some tweaking needed to make the mirrors syntax handle this but that should be possible. Closing some bugs so we link to one bug. *** This bug has been marked as a duplicate of bug 9738 ***