[opensuse-packaging] Package Markup / Package Tagging

older
[opensuse-packaging] Can someone...

Dominique Leuenberger

3 Sep 2010 3 Sep '10

13:50

Fellow packagers, I would like to start a discussion, hopefully resulting in a packaging policy regarding patches in our packages. Very often it is difficult to see in a package, when a patch was added, when it was modified, when disabled, and when deleted. In order to address all those questions, and some more, we would like to globally introduce (for Factory it might become mandatory; autobuild team is considering to enforce the rule), a new policy about this. It mainly consists of one additional line per patch added, the so-called patch markup line, in the .spec file. It looks similar to: # PATCH-FIX-UPSTREAM <packagename>-<whatdoIfix>.patch <bufrefs> <who> -- Description of the patch, possible source. The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description. This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file. - Added patch-super1.patch - Rebased patch-super2.patch - Disabled patch-super1.patch due to API break. NEEDS REBASE - Drop patch-super1.patch, upstream fixed. Thanks to this, an entire story / life of any given patch file can be followed. A patch accidentally dropped is less likely to happen like this. Patches, that are flagged for rebase can be automatically identified and reported on. There is a wiki page explaining the various Types of patches at http://old-en.opensuse.org/Packaging/Patches Looking forward to have a lively, factical discussion going on around this subject. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Show replies by date

Reinhard Max

3 Sep 3 Sep

16:35

Hi, On Fri, 3 Sep 2010 at 15:50, Dominique Leuenberger wrote:

...

The line is as simple as: - Type of Patch

will there be a list of patch types to select from or will the patch type be a free form string?

...

- Patch filename

I think the patch name should not be repeated. It is already mentioned in the respective "Patch:" tag and given a per spec file unique number which the markup line(s) can refer to.

...

- Whom to address in case of questions re: the patch And a short description.

Putting this all on a single line could easily violate the "lines should not exceed 80 chars" rule if the description requires more than a few words. So it should be allowed to continue the description on the following lines and maybe even mandatory to start the description on a separate line. I'd suggest a convention that puts the additonal information next to the respective "Patch:" Tag, e.g. like this: Patch0: foo-bar.patch #P0: INTEGRATION description #P0 description description Patch1: foo-baz.patch #P1: BUGFIX #P1 description description description #P1 continued description Another option would be to put type and person above the actual Patch tag: #P2: ENHANCEMENT Patch3: foo-baz.patch #P3 description description description #P3 continued description Unfortunately rpmbuild doesn't accept comments at the end of Patch: lines, otherwise we could do it this way: Patch4: foo-bar.patch # SECURITY #P4 description description description #P4 continued description cu Reinhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Reinhard Max

16:40

On Fri, 3 Sep 2010 at 18:35, Reinhard Max wrote:

...

Patch0: foo-bar.patch #P0: INTEGRATION description #P0 description description

Whoops, the flowed encoding killed my formatting. This should have been: Patch0: foo-bar.patch #P0: INTEGRATION description #P0 description description cu Reinhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Dominique Leuenberger

16:50

...

...
...
On 09/03/2010 at 6:35 PM, Reinhard Max wrote: Hi,

On Fri, 3 Sep 2010 at 15:50, Dominique Leuenberger wrote:

...
The line is as simple as: - Type of Patch

will there be a list of patch types to select from or will the patch type be a free form string?

the list is limited and is what can be found on the wiki page linked. The valid ones are: PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} plus a special case PATCH-NEEDS-REBASE

...

...
- Patch filename

I think the patch name should not be repeated. It is already mentioned in the respective "Patch:" tag and given a per spec file unique number which the markup line(s) can refer to.

An interesting idea, indeed...

...

...
- Whom to address in case of questions re: the patch And a short description.

Putting this all on a single line could easily violate the "lines should not exceed 80 chars" rule if the description requires more than a few words. So it should be allowed to continue the description on the following lines and maybe even mandatory to start the description on a separate line.

I'm not a big fan of multiline comments. But of course it is a valid idea, and once we agree on a usable form, that fits for everybody, we will bow to it :) Having it all on one line makes automatic parsers easier though. Such scripts DO exist already: http://tmp.vuntz.net/opensuse-packages/patch.py?project=GNOME%3AFactory Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Reinhard Max

17:03

On Fri, 3 Sep 2010 at 18:50, Dominique Leuenberger wrote:

...

the list is limited and is what can be found on the wiki page linked. The valid ones are: PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} plus a special case PATCH-NEEDS-REBASE

Ah - I had overlooked that part. But I think there are some cases that are not covered by the list as it is: 1. Integration work that qualifies neither as a fix nor as a feature nor will it ever go upstream. The kind of stuff I usually collect under a generic packagename.patch unless there are parts that are large enough to justify a patch file of their own. 2. I wonder if there should be a specific flag for security patches (besides the fact that they often have the CVE number in the file name). cu Reinhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Sascha 'saigkill' Manns

4 Sep 4 Sep

13:40

New subject: Rebase Was: Re: [opensuse-packaging] Package Markup / Package Tagging

Am Friday 03 September 2010 18:50:52 wrote Dominique Leuenberger:

...

...
...
...
On 09/03/2010 at 6:35 PM, Reinhard Max wrote: Hi,

On Fri, 3 Sep 2010 at 15:50, Dominique Leuenberger wrote:

...
The line is as simple as: - Type of Patch

will there be a list of patch types to select from or will the patch type be a free form string?

the list is limited and is what can be found on the wiki page linked. The valid ones are: PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} plus a special case PATCH-NEEDS-REBASE What means "rebase"? I never heard this before.

-- Sincerely yours Sascha Manns open-slx GmbH openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English)

Will Stephenson

14:04

New subject: Rebase Was: Re: [opensuse-packaging] Package Markup / Package Tagging

On Saturday 04 September 2010 15:40:58 Sascha 'saigkill' Manns wrote:

...

Am Friday 03 September 2010 18:50:52 wrote Dominique Leuenberger:

...
...
...
...
On 09/03/2010 at 6:35 PM, Reinhard Max wrote: Hi,

On Fri, 3 Sep 2010 at 15:50, Dominique Leuenberger wrote:

...
The line is as simple as: - Type of Patch

will there be a list of patch types to select from or will the patch type be a free form string?

the list is limited and is what can be found on the wiki page linked. The valid ones are: PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} plus a special case PATCH-NEEDS-REBASE

What means "rebase"? I never heard this before.

Generally it means to change the basis of a patch, usually to make a patch based on old code apply to (be based on) on a newer version. Here's a german explanation of the git rebase command, which probably includes a lot of git specific stuff but the concept is the same: http://de.gitready.com/intermediate/2009/01/31/intro-to-rebase.html HTH Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Sascha 'saigkill' Manns

16:33

New subject: Rebase Was: Re: [opensuse-packaging] Package Markup / Package Tagging

Am Saturday 04 September 2010 16:04:37 wrote Will Stephenson:

...

On Saturday 04 September 2010 15:40:58 Sascha 'saigkill' Manns wrote:

...
Am Friday 03 September 2010 18:50:52 wrote Dominique Leuenberger:

...
...
...
...
On 09/03/2010 at 6:35 PM, Reinhard Max wrote: Hi,

On Fri, 3 Sep 2010 at 15:50, Dominique Leuenberger wrote:

...
The line is as simple as: - Type of Patch

will there be a list of patch types to select from or will the patch type be a free form string?

the list is limited and is what can be found on the wiki page linked. The valid ones are: PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} plus a special case Have we any specs who i can see how it shows in reality?

Dominique Leuenberger

17:09

New subject: Rebase Was: Re: [opensuse-packaging] Package Markup / Package Tagging

...

...
...
On 09/04/2010 at 6:33 PM, "Sascha 'saigkill' Manns" Have we any specs who i can see how it shows in reality?

You can have a look at various packages in GNOME:Factory for example. GDM in Factory has various patches that are tagged as an exampple https://build.opensuse.org/package/view_file?file=gdm.spec&package=gdm&project=openSUSE%3AFactory&srcmd5=c00cf0ae22daaf2184b6451f70096282 Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Petr Mladek

3 Sep 3 Sep

19:07

Reinhard Max píše v Pá 03. 09. 2010 v 18:35 +0200:

...

I'd suggest a convention that puts the additonal information next to the respective "Patch:" Tag, e.g. like this:

Patch0: foo-bar.patch #P0: INTEGRATION description #P0 description description

Patch1: foo-baz.patch #P1: BUGFIX #P1 description description description #P1 continued description

I suggest to switch the oder. Programmers usually put comments before the relevant code. Then the prefix "Px" would not be needed: # INTEGRATION description # description description Patch0: foo-bar.patch # BUGFIX # description description description # continued description Patch1: foo-baz.patch BTW: GNOME team already uses similar rules. I am not sure where they are described. For example, see the packages: mc, metacity, gnome-session. -- Best Regards, Petr Mladek software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: pmladek@suse.cz Lihovarská 1060/12 tel: +420 284 028 952 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Dominique Leuenberger

19:44

...

...
...
On 09/03/2010 at 9:07 PM, Petr Mladek wrote: Reinhard Max píše v Pá 03. 09. 2010 v 18:35 +0200: I'd suggest a convention that puts the additonal information next to the respective "Patch:" Tag, e.g. like this:

Patch0: foo-bar.patch #P0: INTEGRATION description #P0 description description

Patch1: foo-baz.patch #P1: BUGFIX #P1 description description description #P1 continued description

I suggest to switch the oder. Programmers usually put comments before the relevant code. Then the prefix "Px" would not be needed:

Spec files are not written by programmers. We emphasize all the time that a contributor can help with packaging withoutprogramming knowlegde (of course there is a limit.. but I stay with this statement). Also: multi line comments like this are a pain to parse for statistics... I already gave a link to an overview, where those tags are already parsed.

...

# INTEGRATION description # description description Patch0: foo-bar.patch

# BUGFIX # description description description # continued description Patch1: foo-baz.patch

BTW: GNOME team already uses similar rules. I am not sure where they are described. For example, see the packages: mc, metacity, gnome-session.

The gnome team uses the documented from found at http://old-en.opensuse.org/Packaging/Patches (the same link as posted in the thread start... the same format suggested there). Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Reinhard Max

20:48

On Fri, 3 Sep 2010 at 21:07, Petr Mladek wrote:

...

I suggest to switch the oder. Programmers usually put comments before the relevant code.

Indeed, but I wouldn't call a patch tag *code*. Look at it as a glossary or the entry in a dictionary where the patch tag is the keyword and the comments are the explanation.

...

Then the prefix "Px" would not be needed:

Whether or not a Px prefix is used is independent from the question where the commets are placed relative to the patch tag. I suggested them to avoid confusion between regular comments and these special comments, and to reduce the risk of messing up the comments when moving around blocks. Or to put it a different way: When the Px prefix is there, it doesn't really matter where the comments are placed, so it can be left up to the individual packager to decide what works better for him. cu Reinhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stephan Kulow

6 Sep 6 Sep

09:30

Am Freitag 03 September 2010 schrieb Petr Mladek:

...

Reinhard Max píše v Pá 03. 09. 2010 v 18:35 +0200:

...
I'd suggest a convention that puts the additonal information next to the respective "Patch:" Tag, e.g. like this:

Patch0: foo-bar.patch #P0: INTEGRATION description #P0 description description

Patch1: foo-baz.patch #P1: BUGFIX #P1 description description description #P1 continued description

I suggest to switch the oder. Programmers usually put comments before the relevant code. Then the prefix "Px" would not be needed:

# INTEGRATION description # description description Patch0: foo-bar.patch

# BUGFIX # description description description # continued description Patch1: foo-baz.patch

If you do that format, it will be very hard for a program to decide if this is a tagged patch or something else. Think of # BUGFIX # really cool description of old patch # Patch0: oldpatch Patch1: foo-baz.patch So either repeat the number - or even more secure the name of the patch. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Lubos Lunak

3 Sep 3 Sep

17:27

On Friday 03 of September 2010, Dominique Leuenberger wrote:

...

Fellow packagers,

I would like to start a discussion, hopefully resulting in a packaging policy regarding patches in our packages. Very often it is difficult to see in a package, when a patch was added, when it was modified, when disabled, and when deleted.

In order to address all those questions, and some more, we would like to globally introduce (for Factory it might become mandatory; autobuild team is considering to enforce the rule), a new policy about this.

Has the option that the build service would be actually usable as a revision control system been considered?

...

This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file.

I really dislike the fact that the changelogs of our packages include from users' point of view completely irrelevant developer information. If the build service is not good enough for this on its own, it at least shouldn't be in the package's changelog. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Marcus Rueckert

17:47

On 2010-09-03 19:27:15 +0200, Lubos Lunak wrote:

...

...
This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file.

I really dislike the fact that the changelogs of our packages include from users' point of view completely irrelevant developer information. If the build service is not good enough for this on its own, it at least shouldn't be in the package's changelog.

it has to be in the changelog to find out when and why a patch got removed. this information is also interesting for users when they want to find out why a fix/feature got removed. trust me ... walking down the history to find out when a patch got removed and then guessing why is no fun. I had to do that more than once already. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Lubos Lunak

18:22

On Friday 03 of September 2010, Marcus Rueckert wrote:

...

On 2010-09-03 19:27:15 +0200, Lubos Lunak wrote:

...
...
This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file.

I really dislike the fact that the changelogs of our packages include from users' point of view completely irrelevant developer information. If the build service is not good enough for this on its own, it at least shouldn't be in the package's changelog.

it has to be in the changelog to find out when and why a patch got removed.

No, it doesn't have to be. It is just that the build service as a revision control system loses even to CVS. I may be a snooty developer, but I find it rather sad to repeatedly do manually something that a machine could do.

...

this information is also interesting for users when they want to find out why a fix/feature got removed.

I'm sure they're all dying to find out things like "Add libsoprano-devel Require to libkde4-devel", "package baselibs.conf", "refresh patch to compile on factory" (all real examples), or, with this new policy, something along the lines of "drop nepomuk-final.diff patch, included upstream".

...

trust me ... walking down the history to find out when a patch got removed and then guessing why is no fun. I had to do that more than once already.

I've done that countless times with code in some repository. Noticeably less painful than figuring it out from changelogs. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Marcus Rueckert

18:49

On 2010-09-03 20:22:53 +0200, Lubos Lunak wrote:

...

On Friday 03 of September 2010, Marcus Rueckert wrote:

...
On 2010-09-03 19:27:15 +0200, Lubos Lunak wrote:

...
...
This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file.

I really dislike the fact that the changelogs of our packages include from users' point of view completely irrelevant developer information. If the build service is not good enough for this on its own, it at least shouldn't be in the package's changelog.

it has to be in the changelog to find out when and why a patch got removed.

No, it doesn't have to be. It is just that the build service as a revision control system loses even to CVS. I may be a snooty developer, but I find it rather sad to repeatedly do manually something that a machine could do.

...
this information is also interesting for users when they want to find out why a fix/feature got removed.

I'm sure they're all dying to find out things like "Add libsoprano-devel Require to libkde4-devel", "package baselibs.conf", "refresh patch to compile on factory" (all real examples), or, with this new policy, something along the lines of "drop nepomuk-final.diff patch, included upstream".

yes. one of the users are reviewer of submissions. they really like to know why you removed the patch. maybe also other packager on the same package. and the whole thing should also work without getting an obs account (if that is even enough, see below) to look up why the patch got added/removed.

...

...
trust me ... walking down the history to find out when a patch got removed and then guessing why is no fun. I had to do that more than once already.

I've done that countless times with code in some repository. Noticeably less painful than figuring it out from changelogs.

"less *.changes" -> /foo.patch is much faster than hunting through osc log? maybe autobuild (because the patch got added/removed before the obs times) if you see some need to automated the work for yourself, then feel free. but for communication with users and other packagers those extra informations are very helpful. and trust me i see hundreds of packages every week. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Lubos Lunak

6 Sep 6 Sep

14:00

On Friday 03 of September 2010, Marcus Rueckert wrote:

...

yes. one of the users are reviewer of submissions. they really like to know why you removed the patch. maybe also other packager on the same package.

There's no good reason why they would have to look in the package changelog though.

...

and the whole thing should also work without getting an obs account (if that is even enough, see below) to look up why the patch got added/removed.

Sure, why not optimize for a corner case.

...

...
...
trust me ... walking down the history to find out when a patch got removed and then guessing why is no fun. I had to do that more than once already.

I've done that countless times with code in some repository. Noticeably less painful than figuring it out from changelogs.

"less *.changes" -> /foo.patch

is much faster than hunting through osc log

Hunting? You've never used a proper VCS, have you? How can manually fiddling with a manually written file be better than 'vcs log <the-thing-you-want>' ? Which gets me back to the original question that nobody has answered yet. Has the option that the build service would be actually usable as a revision control system been considered?

...

if you see some need to automated the work for yourself, then feel free. but for communication with users and other packagers those extra informations are very helpful. and trust me i see hundreds of packages every week.

I'm not disputing the need of the information. I just disagree with your opinion that things have to be done the tedious way because they always have. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Andreas Gruenbacher

14:14

On Monday 06 September 2010 16:00:46 Lubos Lunak wrote:

...

I'm not disputing the need of the information. I just disagree with your opinion that things have to be done the tedious way because they always have.

Currently, some operations on packages in the build service lose the change history. Not losing history would nicely solve this problem. I agree that fixing how version control is done in the build service would be a lot better than coming up with all sorts of workarounds. (It's not easy to pull of, though.) Andreas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Ludwig Nussel

8 Sep 8 Sep

11:44

Andreas Gruenbacher wrote:

...

On Monday 06 September 2010 16:00:46 Lubos Lunak wrote:

...
I'm not disputing the need of the information. I just disagree with your opinion that things have to be done the tedious way because they always have.

Currently, some operations on packages in the build service lose the change history. Not losing history would nicely solve this problem. I agree that fixing how version control is done in the build service would be a lot better than coming up with all sorts of workarounds. (It's not easy to pull of, though.)

FWIW Fedora has switched to git to store spec files etc (they used CVS before): http://lists.fedoraproject.org/pipermail/devel-announce/2010-July/000647.htm... http://fedoraproject.org/wiki/Using_Fedora_GIT cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stefan Seyfried

3 Sep 3 Sep

18:05

On Fri, 3 Sep 2010 19:27:15 +0200 Lubos Lunak wrote:

...

Has the option that the build service would be actually usable as a revision control system been considered?

IMHO it is totally useless for that. Once you branch, link or do something similar with a package, you lose all history, and I never managed to get a diff of two revisions when I needed it. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Karl Eichwalder

10 Sep 10 Sep

08:30

Lubos Lunak writes:

...

I really dislike the fact that the changelogs of our packages include from users' point of view completely irrelevant developer information. If the build service is not good enough for this on its own, it at least shouldn't be in the package's changelog.

But the rpm changelog are meant to track packaging related changes and references to NEWS or CHANGES files coming with the package. If the user is not interested in packaging related issues, he must not read the --changelog out, but stick with the contents of /usr/share/doc/packages/<PACKAGE>/{NEWS,CHANGES} and continue with reading from there. -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Will Stephenson

3 Sep 3 Sep

21:13

On Friday 03 September 2010 15:50:38 Dominique Leuenberger wrote:

...

I would like to start a discussion, hopefully resulting in a packaging policy regarding patches in our packages. Very often it is difficult to see in a package, when a patch was added, when it was modified, when disabled, and when deleted.

In order to address all those questions, and some more, we would like to globally introduce (for Factory it might become mandatory; autobuild team is considering to enforce the rule), a new policy about this.

I'm all for a standard packaging policy, but before we go rushing into any one implementation's details, can I draw the thread's attention to the existing cross-distribution proposal for a standard patch metadata policy? A common patch tagging system would be useful for sharing work with upstreams and other distros. Proposal: http://dep.debian.net/deps/dep3/ Discussion: http://lists.freedesktop.org/archives/distributions/2009- June/000316.html This policy is also in use at openSUSE: http://old-en.opensuse.org/KDE/Patch_Annotation_Policy Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

4 Sep 4 Sep

05:18

Am 03.09.10 15:50, schrieb Dominique Leuenberger:

...

The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description.

Why don't you put such information in the patch header where it belongs? Regards, Bernhard

Marcus Rueckert

10:13

On 2010-09-04 07:18:51 +0200, Bernhard Walle wrote:

...

Am 03.09.10 15:50, schrieb Dominique Leuenberger:

...
The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description.

Why don't you put such information in the patch header where it belongs?

it is easier to parse a few single line entries in spec files to create stats, than tons of patch files. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

12:07

Am 04.09.2010 12:13, schrieb Marcus Rueckert:

...

On 2010-09-04 07:18:51 +0200, Bernhard Walle wrote:

...
Am 03.09.10 15:50, schrieb Dominique Leuenberger:

...
The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description.

Why don't you put such information in the patch header where it belongs?

it is easier to parse a few single line entries in spec files to create stats, than tons of patch files.

Why? Regards, Bernhard

Wolfgang Rosenauer

14:05

Hi, Am 04.09.2010 14:07, schrieb Bernhard Walle:

...

Am 04.09.2010 12:13, schrieb Marcus Rueckert:

...
On 2010-09-04 07:18:51 +0200, Bernhard Walle wrote:

...
Am 03.09.10 15:50, schrieb Dominique Leuenberger:

...
The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description.

Why don't you put such information in the patch header where it belongs?

it is easier to parse a few single line entries in spec files to create stats, than tons of patch files.

Why?

Currently I have the needed information in my patch headers and I hate to have even more cruft in the spec file. Its formatting is already pretty unreadable (even more as autobuild thinks it has to reformat to whatever it thinks is correct. This "thinking" has bugs since years. (Or is this gone meanwhile? I stopped fixing the format probably a year ago since every Factory commit broke it again). Personally I like the KDE approach like in http://old-en.opensuse.org/KDE/Patch_Annotation_Policy better. It's similar to the style I use in mozilla nowadays. The initial proposal with patch meta in the specfile doesn't convince me. The mentioning of added and dropped patches in the changes makes sense and usually I do that. So I'm not sure if we can get an agreement between all Factory contributors and if it's enforced then be warned about the consequences. At least I'm not sure if I would like to follow that policy. Someone else is invited to reformat my spec files for Factory but I might not care anymore. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Wolfgang Rosenauer

14:07

oh, and sorry for bad quoting and replying as I accidentally removed the earlier messages so this was not a reply to Bernhard but a comment to the overall discussion. Am 04.09.2010 16:05, schrieb Wolfgang Rosenauer:

...

Currently I have the needed information in my patch headers and I hate to have even more cruft in the spec file. Its formatting is already pretty unreadable (even more as autobuild thinks it has to reformat to whatever it thinks is correct. This "thinking" has bugs since years. (Or is this gone meanwhile? I stopped fixing the format probably a year ago since every Factory commit broke it again).

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

15:46

Hi, Am 04.09.10 16:05, schrieb Wolfgang Rosenauer:

...

Personally I like the KDE approach like in http://old-en.opensuse.org/KDE/Patch_Annotation_Policy better. It's similar to the style I use in mozilla nowadays.

Indeed. KDE seems to use it, Mozilla seems to use it, and the kernel use a similar style since ages. The spec file even gets auto-generated there and the patches are in a tarball, so the proposed scheme wouldn't even work. Regards, Bernhard

Will Stephenson

16:59

On Saturday 04 September 2010 17:46:09 Bernhard Walle wrote:

...

Hi,

Am 04.09.10 16:05, schrieb Wolfgang Rosenauer:

...
Personally I like the KDE approach like in http://old-en.opensuse.org/KDE/Patch_Annotation_Policy better. It's similar to the style I use in mozilla nowadays.

Indeed. KDE seems to use it, Mozilla seems to use it, and the kernel use a similar style since ages. The spec file even gets auto-generated there and the patches are in a tarball, so the proposed scheme wouldn't even work.

And as I said in the other mail, Debian and Ubuntu use in-patch metadata. It helps us communicating patches back to upstream and sharing sideways (other distributions). It would also help cross-distribution builds in the OBS. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz

5 Sep 5 Sep

10:35

Le samedi 04 septembre 2010, à 14:07 +0200, Bernhard Walle a écrit :

...

Am 04.09.2010 12:13, schrieb Marcus Rueckert:

...
On 2010-09-04 07:18:51 +0200, Bernhard Walle wrote:

...
Am 03.09.10 15:50, schrieb Dominique Leuenberger:

...
The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description.

Why don't you put such information in the patch header where it belongs?

it is easier to parse a few single line entries in spec files to create stats, than tons of patch files.

Why?

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. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

11:39

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? 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 '%'. Regards, Bernhard

Marcus Rueckert

12:08

On 2010-09-05 13:39:54 +0200, Bernhard Walle wrote:

...

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?

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 '%'.

you want to read it again. it is a script that is generating stats and overview pages from those lines, not his editor. the link was posted already in this thread. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

12:16

Am 05.09.2010 14:08, schrieb Marcus Rueckert:

...

you want to read it again. it is a script that is generating stats and overview pages from those lines, not his editor.

Maybe you should read the posting again before telling me what to do. He said: "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." And my second paragraph was referring to that statement. Regards, Bernhard

Reinhard Max

6 Sep 6 Sep

11:00

On Sun, 5 Sep 2010 at 14:08, Marcus Rueckert wrote:

...

you want to read it again. it is a script that is generating stats and overview pages from those lines, not his editor.

such a script should be running on the server side where opening a file and reading a few line is cheap. OTOH, depending on the individual packager's habits, metadata that is put into the patch file can easily get lost. So my conclusion is, that if we really fail to get the build service itself to track it for us (including branches and submits), the best place to track description *and* history of a patch is the package change log (either the .changes file or the %changelog section of the spec file). cu Reinhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Pavol Rusnak

11:05

On 09/06/2010 01:00 PM, Reinhard Max wrote:

...

So my conclusion is, that if we really fail to get the build service itself to track it for us (including branches and submits), the best place to track description *and* history of a patch is the package change log (either the .changes file or the %changelog section of the spec file).

If we fail to get the build service to track it for us, we should try even harder to make it so. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz

5 Sep 5 Sep

12:13

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. (and yes, I'm talking about *my* use case; I'm not saying everybody works this way) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

12:22

Am 05.09.2010 14:13, schrieb Vincent Untz:

...

...
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.

I agree there.

...

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.

I can imagine that, but forcing every developer to do something (which is what a "policy" is doing) needs a bit more justification, IMO.

...

...
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.

If we would have an agreement about the name of the tags in the patches, it wouldn't be difficult to write a command for osc that shows a nice overview about all patches. Imagine 50 patches (which is what we definitively have in some packages in openSUSE or in SLES at least at the time I worked for the company called Novell, so that's not a hypothetic scenario and no, I don't talk about the kernel or Samba which have their own patch management scripts). Then with the proposed 4 line tags that would be 250 lines of code in the spec file. I wouldn't call that "clear" but much more confusing than having the patch description inside the patches and some scripts to get the overview. Regards, Bernhard

Jean Delvare

7 Sep 7 Sep

14:16

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

Richard Guenther

16:37

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 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.

FWIW I agree. Richard.

Michal Marek

6 Sep 6 Sep

08:06

On 5.9.2010 12:35, Vincent Untz wrote:

...

Le samedi 04 septembre 2010, à 14:07 +0200, Bernhard Walle a écrit :

...
Am 04.09.2010 12:13, schrieb Marcus Rueckert:

...
On 2010-09-04 07:18:51 +0200, Bernhard Walle wrote:

...
Why don't you put such information in the patch header where it belongs?

it is easier to parse a few single line entries in spec files to create stats, than tons of patch files.

Why?

Because a script to get stats about patches has to download just the spec files, instead of downloading all patches in addition to that.

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. Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Dominique Leuenberger

08:18

...

...
...
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? 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 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?) Especially when doing an upgrade of a package with 20 patches, it can be so very helpful to know immediately which patches make sense. An update of a package typically makes me open two files: the .changes to document what I do and the .spec to fix the build and remove unneeded stuff and add new deps as needed. A patch that still applies to not mean it's still needed! Having the bnc/kde/bgo whatever bug id can help spot that a patch is no longer required. Yes, packaging IS taking time, it's not to be handled in 4 minutes during lunch break. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michal Marek

08:49

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

Michal Marek

08:53

On 6.9.2010 10:49, Michal Marek wrote:

...

Or even better, let each time work the way they think is most efficient ^^^^ This should read "team".

...

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

Dominique Leuenberger

09:10

...

...
...
On 09/06/2010 at 10:49 AM, Michal Marek wrote: 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.

Are they??? Isn't the spirit of opensource to bring those patches back upstream? Having a package that is supposed to keep it's patches around just sounds broken.

...

...
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".

Having the comment of the patch in the preamble helps understanding what a patch is for, without switching to all the other 20 files in the folder. Additionally it helps the autobuild team to understand why a patch get's there. Of course I don't expect that autobuild is going to enforce this on team like kernel, which has a complete different approach on patches and a different source control anyway. But that's up to autobuild to decide to whom they feel like granting an exception would make sense. Every good rule has it's exception. Nothing new there. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michal Marek

09:51

On 6.9.2010 11:10, Dominique Leuenberger wrote:

...

...
...
...
On 09/06/2010 at 10:49 AM, Michal Marek wrote: 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.

Are they??? Isn't the spirit of opensource to bring those patches back upstream? Having a package that is supposed to keep it's patches around just sounds broken.

For Factory, yes. But packages also need to be maintained after release, and not every upstream project has maintenance branches to follow. Anyway, even in Factory we have packages with lots of patches, and yes, it would be great if the number of patches reduced, but artificially making it hard to maintain large numbers of patches is not the solution.

...

...
...
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".

Having the comment of the patch in the preamble helps understanding what a patch is for without switching to all the other 20 files in the folder. Additionally it helps the autobuild team to understand why a patch get's there.

Having good patch filenames helps you as well, the rest can live in the patch headers. The autobuild team has to review the patches themselves anyway. To me it really looks like the goal is to make Vincent's statistics work fast and reliable and anything else is secondary to that. Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz

10:03

Le lundi 06 septembre 2010, à 11:51 +0200, Michal Marek a écrit :

...

Having good patch filenames helps you as well, the rest can live in the patch headers. The autobuild team has to review the patches themselves anyway. To me it really looks like the goal is to make Vincent's statistics work fast and reliable and anything else is secondary to that.

I'm sorry if it looks this way, but I can tell you that it's not the goal: I haven't look at the stat page for a while, and I still find those patch tags useful when I look at a package I haven't looked at for a few weeks. Or when I review a change made by someone else. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stephan Kulow

10:11

Am Montag 06 September 2010 schrieb Vincent Untz:

...

Le lundi 06 septembre 2010, à 11:51 +0200, Michal Marek a écrit :

...
Having good patch filenames helps you as well, the rest can live in the patch headers. The autobuild team has to review the patches themselves anyway. To me it really looks like the goal is to make Vincent's statistics work fast and reliable and anything else is secondary to that.

I'm sorry if it looks this way, but I can tell you that it's not the goal: I haven't look at the stat page for a while, and I still find those patch tags useful when I look at a package I haven't looked at for a few weeks. Or when I review a change made by someone else.

Perhaps we can make a compromise and have vital infos in the file name and the rest in the patch itself? This also avoid duplication because if you send the patch upstream, you usually send the file name too. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michael Foerster

10:37

New subject: [opensuse-packaging] Re: Package Markup / Package Tagging

On Mon, 6 Sep 2010, Stephan Kulow wrote:

...

Am Montag 06 September 2010 schrieb Vincent Untz:

...
Le lundi 06 septembre 2010, à 11:51 +0200, Michal Marek a écrit :

...
Having good patch filenames helps you as well, the rest can live in the patch headers. The autobuild team has to review the patches themselves anyway. To me it really looks like the goal is to make Vincent's statistics work fast and reliable and anything else is secondary to that.

I'm sorry if it looks this way, but I can tell you that it's not the goal: I haven't look at the stat page for a while, and I still find those patch tags useful when I look at a package I haven't looked at for a few weeks. Or when I review a change made by someone else.

Perhaps we can make a compromise and have vital infos in the file name and the rest in the patch itself? This also avoid duplication because if you send the patch upstream, you usually send the file name too.

Seconded. It's one of the nicest things for an original-source (upstream) maintainer if a patch is not only annotated in the patch, but also has a declaring name. "{Package}-{What_do_I_do}-{Version_If_needed}.patch" or similar is nice to have, because it conserves brain-power for more precious things to do. Cheers, and thanks for the constructiv discussion, Michael Förster aka Yamaban.

Jean Delvare

7 Sep 7 Sep

12:17

On Saturday 04 September 2010 07:18:51 am Bernhard Walle wrote:

...

Am 03.09.10 15:50, schrieb Dominique Leuenberger:

...
The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description.

Why don't you put such information in the patch header where it belongs?

Yes, please! -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

4970

Age (days ago)

4977

Last active (days ago)

List overview

Download

49 comments

20 participants

participants (20)

Andreas Gruenbacher
Bernhard Walle
Dominique Leuenberger
Jean Delvare
Karl Eichwalder
Lubos Lunak
Ludwig Nussel
Marcus Rueckert
Michael Foerster
Michal Marek
Pavol Rusnak
Petr Mladek
Reinhard Max
Richard Guenther
Sascha 'saigkill' Manns
Stefan Seyfried
Stephan Kulow
Vincent Untz
Will Stephenson
Wolfgang Rosenauer