[opensuse-packaging] Hidden patches/updated tarballs
Hi, I just started helping review team with reviews and I'm running into people who instead of creating patches and documenting them just update and change tarball (without bumping the version) effectivelly hiding patches inside. It is obviously wrong, but I was asked for the policy and I'm failing to find it. Anybody can help? Apart from that, what are the best practices for git snaphot packages? It can be related... Thanks -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Feb 28, 2014 at 04:44:29PM +0100, Michal Hrusecky wrote:
I just started helping review team with reviews and I'm running into people who instead of creating patches and documenting them just update and change tarball (without bumping the version) effectivelly hiding patches inside.
It is obviously wrong, [...]
Is it? How is updating a patch different? (But yes, autogenerated tarballs should contain a date or a git revision.) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder - 16:53 28.02.14 wrote:
On Fri, Feb 28, 2014 at 04:44:29PM +0100, Michal Hrusecky wrote:
I just started helping review team with reviews and I'm running into people who instead of creating patches and documenting them just update and change tarball (without bumping the version) effectivelly hiding patches inside.
It is obviously wrong, [...]
Is it? How is updating a patch different?
Well, we have so many policies about tracking patches... If we allow people to simply change the content of the tarball (without version change) instead of doing real patch, it's pointless to track patches as we have no idea whether the tarball is upstream one or how many bundled patches it contains. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 2014-02-28 at 17:32 +0100, Michal Hrusecky wrote:
Michael Schroeder - 16:53 28.02.14 wrote:
On Fri, Feb 28, 2014 at 04:44:29PM +0100, Michal Hrusecky wrote:
I just started helping review team with reviews and I'm running into people who instead of creating patches and documenting them just update and change tarball (without bumping the version) effectivelly hiding patches inside.
It is obviously wrong, [...]
Is it? How is updating a patch different?
Well, we have so many policies about tracking patches... If we allow people to simply change the content of the tarball (without version change) instead of doing real patch, it's pointless to track patches as we have no idea whether the tarball is upstream one or how many bundled patches it contains.
I fully agree with Michal here. It's about consistency and reproducibility. If a tarball 'changes' but versions stay, it's close to impossible to reproduce. There is, though, no policy in place to decline a replaced tarball, because: a Tarball normally is produced by an upstream (which, openSUSE Project at large might be the upstream of openSUSE Distribution). Any upstream that replaces a tarball with a different but equal name is to be publicly flamed and tortured. We're not thinking about playground here... It's my understanding that we're trying to make a solid distribution; The teams within the openSUSE Project that are actually producing some code shall please also take their roles serious. And properly work with the tools given (a great example, if I may, is the YaST-Team, who seems not to have any issues with this! So it IS possible.. it requires discipline though) Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri 28 Feb 2014 05:41:31 PM CST, Dimstar / Dominique Leuenberger wrote:
On Fri, 2014-02-28 at 17:32 +0100, Michal Hrusecky wrote:
Michael Schroeder - 16:53 28.02.14 wrote:
On Fri, Feb 28, 2014 at 04:44:29PM +0100, Michal Hrusecky wrote:
I just started helping review team with reviews and I'm running into people who instead of creating patches and documenting them just update and change tarball (without bumping the version) effectivelly hiding patches inside.
It is obviously wrong, [...]
Is it? How is updating a patch different?
Well, we have so many policies about tracking patches... If we allow people to simply change the content of the tarball (without version change) instead of doing real patch, it's pointless to track patches as we have no idea whether the tarball is upstream one or how many bundled patches it contains.
I fully agree with Michal here. It's about consistency and reproducibility. If a tarball 'changes' but versions stay, it's close to impossible to reproduce.
There is, though, no policy in place to decline a replaced tarball, because:
a Tarball normally is produced by an upstream (which, openSUSE Project at large might be the upstream of openSUSE Distribution). Any upstream that replaces a tarball with a different but equal name is to be publicly flamed and tortured.
We're not thinking about playground here... It's my understanding that we're trying to make a solid distribution; The teams within the openSUSE Project that are actually producing some code shall please also take their roles serious. And properly work with the tools given (a great example, if I may, is the YaST-Team, who seems not to have any issues with this! So it IS possible.. it requires discipline though)
Dominique Hi There is this document; https://en.opensuse.org/SourceUrls
-- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.2 Kernel 3.11.10-7-desktop up 6 days 19:39, 3 users, load average: 0.07, 0.07, 0.12 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dimstar / Dominique Leuenberger wrote:
On Fri, 2014-02-28 at 17:32 +0100, Michal Hrusecky wrote:
Michael Schroeder - 16:53 28.02.14 wrote:
On Fri, Feb 28, 2014 at 04:44:29PM +0100, Michal Hrusecky wrote:
I just started helping review team with reviews and I'm running into people who instead of creating patches and documenting them just update and change tarball (without bumping the version) effectivelly hiding patches inside.
It is obviously wrong, [...]
Is it? How is updating a patch different?
Well, we have so many policies about tracking patches... If we allow people to simply change the content of the tarball (without version change) instead of doing real patch, it's pointless to track patches as we have no idea whether the tarball is upstream one or how many bundled patches it contains.
I fully agree with Michal here. It's about consistency and reproducibility. If a tarball 'changes' but versions stay, it's close to impossible to reproduce.
OBS always shows the tarball diff... It's been common practice for some packages in the past where the sources in obs were the canonical upstream. Meanwhile hopefully all such packages are hosted in some git repo. There are still scripts that produce tarballs with fixed names for legacy reasons. It sometimes just takes a few minutes of work to convert. Still someone has to do the work, test it, communicate it to the contributors, see if it also works with branches etc, etc. Also, as Michal said there are plans to have OBS support scms directly without the need to upload tarballs. So maybe it's not the right time to try changing the policy yet. I don't know the timeline for that feature but once it's there the problem of unversioned tarballs simply becomes obsolete. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Feb 28, 2014 at 05:32:06PM +0100, Michal Hrusecky wrote:
Well, we have so many policies about tracking patches... If we allow people to simply change the content of the tarball (without version change) instead of doing real patch, it's pointless to track patches as we have no idea whether the tarball is upstream one or how many bundled patches it contains.
Well, the point I was making is that I can change the content of a patch in any way I like, so is it ok for you if I submit a package as a single big patch file? Anyway, I don't think this is really about people not doing real patches. In all cases I know where tarball changes happened, openSUSE is the upstream and the development happens in a SCM. In that case, the tarball is automatically generated by some CI like Jenkins. So there'll never be patches in this case. Most of those packages don't put the commit ids in the tarball name, this should probably be changed to make things easier to understand. At some point in the future OBS will maybe support this even more, then you won't even have a tarball anymore, just the unpacked trees. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Well, we have so many policies about tracking patches... If we allow people to simply change the content of the tarball (without version change) instead of doing real patch, it's pointless to track patches as we have no idea whether the tarball is upstream one or how many bundled patches it contains. Well, the point I was making is that I can change the content of a
On Fri, Feb 28, 2014 at 05:32:06PM +0100, Michal Hrusecky wrote: patch in any way I like, so is it ok for you if I submit a package as a single big patch file?
Anyway, I don't think this is really about people not doing real patches. In all cases I know where tarball changes happened, openSUSE is the upstream and the development happens in a SCM. In that case, the tarball is automatically generated by some CI like Jenkins. So there'll never be patches in this case.
Most of those packages don't put the commit ids in the tarball name, this should probably be changed to make things easier to understand.
At some point in the future OBS will maybe support this even more, then you won't even have a tarball anymore, just the unpacked trees. I think it would be a dangerous move to support dropping tarballs, alot of upstreams build there tarballs with make dist or some equivalent making the tarballs differ from whats available in the source tree normally providing stuff like a configure instead of files that need to have autoreconf called on them. I know Qt also has bigger differences
On 03/04/2014 01:01 AM, Michael Schroeder wrote: then that so i believe it would be a very risky move to allow support for releases that arn't the exact tar that is released by a upstream. Cheers, Simon
Cheers, Michael.
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
"Michael" == Michael Schroeder <mls@suse.de> writes:
Michael> Most of those packages don't put the commit ids in the tarball Michael> name, this should probably be changed to make things easier to Michael> understand. Michael> At some point in the future OBS will maybe support this even Michael> more, then you won't even have a tarball anymore, just the Michael> unpacked trees. Not something I would like to see, as one of the packages I maintain (darktable to be precise), has some patented code that is not possible for opensuse to have even as a source file, hence locally the packager has to run a script to remove the offending code creating a non-patented tarball which is then uploaded to OBS. So in this case the source tarball used for the package is not the same tarball provided by the upstream. I am sure there are other packages like this. Togan -- Life is endless possibilities -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Dienstag, 4. März 2014, 09:35:29 wrote Togan Muftuoglu:
"Michael" == Michael Schroeder <mls@suse.de> writes:
Michael> Most of those packages don't put the commit ids in the tarball Michael> name, this should probably be changed to make things easier to Michael> understand.
Michael> At some point in the future OBS will maybe support this even Michael> more, then you won't even have a tarball anymore, just the Michael> unpacked trees.
Not something I would like to see, as one of the packages I maintain (darktable to be precise), has some patented code that is not possible for opensuse to have even as a source file, hence locally the packager has to run a script to remove the offending code creating a non-patented tarball which is then uploaded to OBS. So in this case the source tarball used for the package is not the same tarball provided by the upstream. I am sure there are other packages like this.
Yes, but that are rare exceptions. The feature Michael is speaking about will be always only one possible option, no features will go away. However, I still hope that we will get a policy for Factory that enables us to trace the upstream sources, no matter if it is a tar ball or any kind of SCM checkout. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Adrian Schröter -
Dimstar / Dominique Leuenberger -
Ludwig Nussel -
Malcolm -
Michael Schroeder -
Michal Hrusecky -
Simon -
Togan Muftuoglu