On Mon, Jun 24, 2019 at 4:35 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Sun, Jun 23, 2019 at 10:15:55AM +0200, Takashi Iwai wrote:
Although seife wanted to stop discussion, I'd still like to add one point: I'd love to have a better alternative for tracking the code in rpm sources.
The main problem is that we're (ab)using rpm changelog for several different purposes. That is, we mess up the rpm changelog contents with both the feature change / bug fix descriptions and the patch change tracking, a la manual VCS. The former is essential, while the latter is useless for non-developers.
As many people already suggested, admittedly, this policy itself is useful and helps for development. Sometimes indicating the added patches helps, indeed. However, overall, relying only on this is definitely no best option: why can't I check the patch changes more simply like "git log some.patch"? And, why do I have to write and edit manually all patch changes in *.changes, which is very error-prone? All these pains show the lack of a proper VCS in the process.
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.
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. -- 真実はいつも一つ！/ 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