Mailinglist Archive: opensuse-packaging (158 mails)

< Previous Next >
Re: [opensuse-packaging] Package Markup / Package Tagging
  • From: Richard Guenther <rguenther@xxxxxxx>
  • Date: Tue, 7 Sep 2010 18:37:11 +0200 (CEST)
  • Message-id: <alpine.LNX.2.00.1009071836160.28912@xxxxxxxxxxxxxx>
On Tue, 7 Sep 2010, Jean Delvare wrote:

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

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

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.

FWIW I agree.

< Previous Next >