On Tue, Jun 25, 2019 at 5:39 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Mon, Jun 24, 2019 at 04:59:22AM -0400, Neal Gompa wrote:
On Mon, Jun 24, 2019 at 4:35 AM Michal Kubecek <mkubecek@suse.cz> wrote:
More and more packages work around the problem in one of two ways:
1. RPM source is tracked in a git repository and export the OBS sources from there (e.g. kernel, samba). They usually also pack all patches into one or multiple tarballs and apply them using a script. While the primary purpose is to avoid ugly and impractical handling of many Patch and %patch lines in specfile (I was told about autosetup some time ago but it only helps with one half of that - and the less annoying one), it also, as a bonus, hides the patches from OBS bots.
2. Complete tarball snatshot from a normal git repository is exported as a tarball into RPM source and there are no patches at all. With no patches, there is nothing to track and nothing for the bot to check.
What both these approaches have in common is that with no usable version control in OBS, they move the actual package maintenance somewhere else (in a git repository) and only export the result into OBS. The downside is that there may be people (and bots) unaware of the fact who tend to modify the package in OBS rather than applying the changes to the place where the package is actually maintained.
I hate both of these options. I already hate the fact that some of the core packages are doing this, because it also means we're forking packages. Once you start doing that, it becomes really easy disconnect from upstream. We've had this problem for *years* with systemd, for example. I worry that it may also happen with dracut since it switched to this model.
Part of the reason why patching has so much friction is to *reduce* patching and to force *communicating* with upstream instead. If patching is annoying, you're hopefully going to work with upstream to fix issues there. But I think that's gone wrong, because what people are doing instead is just figuring out ways to hide patching.
I might partly agree with this if OBS were used only for Factory packages. For those packages, we should indeed try to minimize the number of patches. I said "partly" because there are packages where the discussion with upstream is... difficult. You mentioned systemd - that's one illustrative example, glibc used to be another. Then there are packages where upstream is effectively dead etc.
You say upstream is difficult, I say downstream doesn't talk to upstream much. Admittedly, my patch load as systemd maintainer in Mageia is nowhere near as big as openSUSE's is now, it was worse when I started. I've upstreamed useful changes from Mageia into systemd upstream (including our improvements to the upstream rpm macros, which openSUSE still doesn't use...) Honestly, this is your own (openSUSE's) fault. I've seen little evidence of communication with upstreams until *very* recently. At least the situation with dracut is improving. Or perhaps I'm more influenced by my beginnings... To me, maintenance of a package begins with introducing myself to upstream and sending fixes/suggestions there to make it better. That was a consequence of how I started out as a Fedora packager. I realize that most other communities don't value that and don't have a directive to try to work with upstream.
However, the main problem with your vision is that OBS is not used only for Factory packages. It's also used for Leap packages and for SLE packages. For these we cannot simply wave hand and say "patching should be hard" (because we need those fixes) or "talk to upstream" (because most of the patches are upstream backports).
And you know what? Those backports should be visible. Hiding them behind git snapshot things rather than declaring the patch set just means you're trying to dodge the auditing process. If the process for handling backport patching in changelogs is too onerous, then let's fix that. It is so frustrating trying to figure out how openSUSE has broken something because they've forked packages and done weird things without any way to figure out what's going on. If I could, I'd ban this practice.
While it would be nice to be able to track packages in OBS reasonably, I'm not sure it's something we can expect for real. Reportedly, someone already did a git based OBS years ago when OBS was new but the OBS guys refused to use his work as they saw no use for it. :-( To do the same again today would be probably way more complicated both from technical and organizational point of view.
It is not complex from a technical point of view. I spoke to the OBS guys about at oSC this year, and I've been doing it for four years at $DAYJOB. I've implemented Fedora-style Dist-Git (packaging Git). I demonstrated a bit of how this looks at oSC with Pagure[1]. There were quite a few people who liked the idea, and if I get an OBS working on Fedora, we'd do it that way anyway, because OBS' VCS sucks.
[1]: https://youtu.be/wastUxOT6IQ?t=1420
So maybe the solution is to do exactly the opposite: forget about OBS version "control" completely and start recommending one of the two models described above (or maybe both) as the standard way to use for packages with non-trivial maintenance. And maybe add some framework to make them a bit easier.
No. If the process for the normal way is broken, let's fix the process. If the tooling is crappy, let's fix the tools. Workarounds only add more pain down the road.
Well, if you can make OBS switch to git as a version control backend, I'll be more than happy. Until then, I'm going to stick with the workarounds for packages requiring non-trivial patch management. I'm not holding my breath but it would be nice to be surprised.
We'll see, I guess... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org