On 6.9.2010 10:18, Dominique Leuenberger wrote:
On 09/06/2010 at 10:06 AM, Michal Marek
wrote: So let's rather put the burden on the packagers? Because editing a two (three, four ... or how much metadata are you going to stuff there) times longer spec file is so much more fun? Requiring people to do more (boring) work just because it is then easier to gather some fancy stats is totally crazy. I really hope this won't become an official policy. And even if it will, I'm not going to follow it, I'm sure you will save so much time by not improving the script that you can maintain these annotations yourselves :-P. Burden? Writing a one phrase sentence with references what the next line is about?
Later in the thread, there were examples with multiline comments.
There are spec files I'm certainly never going to touch. Having a gazillion of patches in any package is not the right thing to do anyway... this simply does not scale and is a pain when an update
But your proposal makes this even less scalable and more painful. Packages with lots of patches are here to stay, the exercise should be to make their maintenance easier, not the opposite.
The tag line is not only for scripts, that's for sure.. but also for other people hacking on your spec files (everybody should be able to touch every package, no?)
I'm not at all convinced that that a preamble interleaved with comments with cryptic tags is more convenient to work with, especially for outsiders. What's the problem with putting any metadata into the patch headers? This is what some other teams are already doing, it is easily extensible and the pairing of patches and metadata is straightforward. Or even better, let each time work the way they think is most efficient for them. I'm also not saying "all packages must have a patches.fixes.tar.bz2 and patches.suse.tar.bz2, this is going to be an autobuild rule starting next week". Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org