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. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org