On Mon, 2019-06-24 at 04:59 -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.
Quite to the contrary, I find that maintaining packages in git encourages working closely with upstream. I am a big fan of Michal's option 2). Fork upstream repo on github or gitlab, maintain a factory branch which is following upstream with a few bug fixes and a few SUSE specific patches, works neatly. Moreover, it facilitates maintaining maintenance branches for SLE and Leap by cherry-picking important fixes from upstream, which is essential for the long-lived distros, where we can't follow upstream all the time. A URL-link to the a repo, plus a commit ID, provides much quicker and deeper insight into the source code changes made than any changelog entry you could think of. Added the bonus that more people are familiar with git/github than osc/OBS, I find this much more appealing than the traditional rpm %patch way of doing things. The only exception IMO is patches that are SUSE-specific and unlikely to ever be taken by upstream (think a feature that upstream dropped and SUSE still supports for some reason). IMO %patch is basically a relict from ancient times when upstream packages were distributed as tarballs exclusively. Regards Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org