Hello, On Jul 25 12:37 Peter Simons wrote (excerpt):
Johannes Meixner writes:
From my point of view it is never ever allowed (even not legally allowed) that an automated tool silently and anonymously modifies sources.
I don't know what you mean by "anonymously" in this context
With "anonymously" I meant what I had also written: --------------------------------------------------------------- I think if there are automated modifications then the automated tool must make its modifications as separated commits and the automated tool must make an appropriate entry in the changelog so that it is clear that the automated tool acts as a separated author. --------------------------------------------------------------- Changes by an automated tool are no changes made by me so that the automated tool must make itself visible as another separated author "who" changed it. I think it could be even legally problematic when changes that are not made by me happen to be public visible as my commit with my commit message and my changelog entry. Strictly speaking: An automated tool that anonymously changes sources lies to others about who changed what.
like, ensuring that all BuildDepends are ordered alphabetically
In general alphabetical ordering is meaningless ( except exceptions like a telephone book ;-) so that usually an enforced alphabetical ordering removes information. For example build requirements should be ordered according to the reason behind why each build requirements are there e.g. something like -------------------------------------------------------------- # For 'configure --enable-fancystuff-all': BuildRequires: fancystuff-devel BuildRequires: fancystuff-extensions BuildRequires: fancystuff-tools # For making HTML and PDF documentation: BuildRequires: docbook BuildRequires: xml-tools BuildRequires: html-tools BuildRequires: ghostscript BuildRequires: pdf-tools -------------------------------------------------------------- In general it seems to be good when openSUSE RPM spec files are in compliance with a reasonable openSUSE standard. But on the other hand enforcing it could be a hindrance for openSUSE contributors to use ready-made RPM spec files from whatever upstream projects also for openSUSE RPMs with only some minor openSUSE-specific adaptions to get software easily built also for openSUSE. What is more important for openSUSE: Be open for others (and accept diversity) or be uniform (to make maintenance easier)? Perhaps only for openSUSE core packages (whatever that exactly means - perhaps packages that are also in SLE ?) the RPM spec files and the RPM changelogs must be in compliance with a standard to make maintenance easier? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org