Mailinglist Archive: opensuse-packaging (53 mails)

< Previous Next >
Re: [opensuse-packaging] Re: patch names: maybe include patch numbers?
* Marcus Meissner <meissner@xxxxxxx> [2015-01-12 14:00]:
On Mon, Jan 12, 2015 at 01:55:11PM +0100, Yamaban wrote:
On Mon, 12 Jan 2015 10:33, Johannes Meixner <jsmeix@...> wrote:
On Jan 11 14:17 Jan Engelhardt wrote (excerpt):
On Sunday 2015-01-11 14:12, Bernhard Voelker wrote:
no, there are just a few, like
1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303,
400, 401, 416, 500, 501, 502, 503

Bernhard Voelker,
can you explain the reason behind why it would be good
to have the number of the patch in its name?

I use the same basic idea as you with separated number blocks
and I also have only a few small patches in my packages.

If a set of patches belongs to each other I would rather prefix
them with a meaningful word instead of a technical number like
fix-GUI-this.patch
fix-GUI-that.patch
enhance-documentation-foo.patch
enhance-documentation-bar.patch

Ideally if several patches belong to each other they should be
provided in on single patch file like
fix-GUI-this_and_that.patch
enhance-documentation-foo_and_bar.patch

But this are only my personal suggestions because I think:

With only a few small patches it is easy to work in any case.

Both "few" plus "small" is essential. (My first package that I
mercilessly cleaned up had basically only one single patch
that was a huge huddle of anything.)

I'm maintaining some 'private' packages for a business, and not all
of them are well maintained from upstream.

So, the patches pile up until the next offical release, where most,
but not all patches are integrated again.

In my case that list reads some thing like this:
[code]
# 'upstream' patches < 1000
0001-4.6.12.001-fix-CVE_xxxx.patch
...
0801-4.6.12.803-fix-config-defaults-TLS.patch

# 'os-release' patches 1001-1999
1001-4.6.x-use-libpng16-for-OSS13.patch
...
1801-4.6.x-disable-SSL2-SSL3-for-sure.patch

# 'private' patches > 2000
2001-disable-user-config.patch
...
2801-config-aftermatch-of-disable-SSL.patch
[/code]

For me, the biggest plus of numbering patches, is
to make it obvious in which order they have to be
applied to work.

It makes sense to seperate 'upstream issues' e.g.
backported bug-fixes that are upstream in the next
version, but we stay on this version,
and 'os-release issues' e.g. we want to add a extra
plugin-dir, or change a config-default to a other value.


It's about makeing like easier for the packager, at just
a glance (s)he can see where a new patch/bug-fix has to
be put in. And it reduces the chance of misordering
patches and getting undesireable results.

These are my 2ct. YMMV.

Larger projects use a "series" file though to keep track of the order,
like our kernel. Then there is no need for this kind of numbering.

And for all other packages one can use quilt:
https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Using_quilt
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >