Salut Vincent, On Sunday 05 September 2010 02:13:14 pm Vincent Untz wrote:
Le dimanche 05 septembre 2010, à 13:39 +0200, Bernhard Walle a écrit :
Am 05.09.2010 12:35, schrieb Vincent Untz:
Because a script to get stats about patches has to download just the spec files, instead of downloading all patches in addition to that.
FWIW, I'm kind of mixed here: using in-patch information is indeed good because other distros are using this. But on the other hand, I really like the fact that all the information is in the spec file, so I don't have to look elsewhere -- and I used this daily when updating packages.
So you want to *duplicate* information just that the script can be kept a bit simpler?
I'm not saying we should duplicate it -- that's the worst solution. I'm just saying that, in my use case, both solution have ups and downs.
And you misread what I wrote since it's not "just" for a script. Having the tags in the spec files does help me too. Daily.
Normally opening a patch in my the editor (vim) is a matter of moving the cursor to the name of the patch and typing "gf", going back is '%'.
And when you have 5 patches and you want to have a quick overview of all of them, you open all files? :-) Having everything in the .spec file is faster in this case.
I don't think that things being slower or faster should be the key for deciding where tags should go, if these things can be automated. For example, if tags are in the patch headers, it's trivial to write a script extracting them and presenting them in the exact format you need. And if you are unhappy about having to download all the patch files for doing so, then it means that the build service itself should implement the feature (either the header summary, or the statistics themselves.) Reasons for having the meta-data included in the patch themselves are many. This ensures that the meta-data stays in sync with the patches (both presence and contents). This makes porting patches back and forth or even across distributions much easier. This doesn't depend on the packaging system. This doesn't depend on the packaging strategy (e.g. auto-generated .spec file.) This is what others (e.g. kernel developers, or I am said, KDE packagers, debian maintainers) have been doing for years, so it is proven to work. "Having everything in a single text file is easier" is a poor man's argument IMHO. Sure it's easier for one's immediate need, but only when you don't have the tools, or don't know how to use them. As soon as you have the tools, and learn how to use them, then you see that the small benefit of easier use came at the cost of more difficult maintenance which could have been avoided. So, meta-info in patch headers, please. .spec files aren't the right place for such information. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org