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. 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. 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. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org