Patch management

Tharbad · 2021-08-22 19:03:51

Hi,

I'm looking for an answer to a question that might be already solved by the Arch team.

Say I have a software package. I didn't write it but it still being updated by a good dev team.
I would like to add patch to it but that patch is only for my specific use case. The dev team refuses.
I understand them.
Actually, I have like ~150 packages like this. I don't want to fork them. That's what debian did and that's tedious.
So instead I want to write patches.

But when I apply them, I would like to verify that I'm applying to the file I created the patch on and not a newer version of it.

So I would like you to recommend me two things:
1) What tool to use? GNU patch? diffmerge?
2) Patch management system. So I could apply them automatically. I can write bash scripts but there must be some OSS software for this.

Ideas will be welcome.

kokoko3k · 2021-08-22 19:43:11

Tharbad wrote:

.
But when I apply them, I would like to verify that I'm applying to the file I created the patch on and not a newer version of it.

What does it mean? You cannot apply patches on old files and mix them with newer ones.
99.9% You'll have a broken software.

Just make PKGBUILDS that applies the patches you want via patch command and keep the PKGBUILD in sync with upstream versions praying that the patches will apply in the future.
Adapt them when they don't.

It is a manual work.

Tharbad · 2021-08-22 20:15:49

kokoko3k wrote:

Tharbad wrote:
.
But when I apply them, I would like to verify that I'm applying to the file I created the patch on and not a newer version of it.
What does it mean? You cannot apply patches on old files and mix them with newer ones.
99.9% You'll have a broken software.

Probably using some hashing to make sure it won't happen.

kokoko3k wrote:

Just make PKGBUILDS that applies the patches you want via patch command and keep the PKGBUILD in sync with upstream versions praying that the patches will apply in the future.
Adapt them when they don't.
It is a manual work.

That's what I'm trying to avoid. It's not like I'm the first one to have some ~100 custom patches to some software. I'm looking for insights on how to manage this.
The only other use case I can think of is a distro. Maybe the linux kernel? https://github.com/archlinux/linux Arch kernel seems to have tons of patches.
How does the dev team manages those?

ayekat · 2021-08-22 20:31:50

Tharbad wrote:

That's what debian did and that's tedious.

Debian's approach isn't really that different from what you see e.g. on Arch.

To patch software, you need some codebase to work on and generate the patch files from (i.e. your own, downstream fork).
The only difference between Arch and Debian is that on Arch, you only see the resulting patch file that the packager put there, but not the working copy of the upstream codebase (well, with some exceptions: see the Linux package you linked there).
Debian packagers on the other hand lay it all open (i.e. the upstream codebase + the patches they apply).

But in the end, the workflow itself is pretty much the same: Get the upstream code, apply your changes, generate the patch files, and then some packaging work.

And yes, it's tedious. There's a reason why people usually try to get things merged upstream, and usually try to limit their set of patches to backports.
You can use Git to track and rebase your changes to avoid some of the mistakes, but ultimately, there is no magic bullet. It's mainly manual labour.

Trilby · 2021-08-22 20:50:35

Tharbad wrote:

That's what I'm trying to avoid.

This doesn't really make sense. If an old patch will work on the new code, great, move forward. If the old patch would not work on new code, you have to A) modify the patch, or B) not use the new software. There is no way to automate yourself out of a logical necessity.

kokoko3k · 2021-08-22 21:06:31

Tharbad wrote:

Probably using some hashing to make sure it won't happen.

Oh, I think i got it now:
even if the patch would succeed, you still dont want to patch the updated file to avoid unpredictable software behaviour (?)
I can't help on that, sorry, but by personal experience, no cat has ever been killed by a successfull patch, even if the file to patch was updated.
If the context is sufficiently wrong, patch will warn you and refuses to modify the file.

Last edited by kokoko3k (2021-08-22 21:09:53)

Tharbad · 2021-08-23 15:58:57

kokoko3k wrote:

Tharbad wrote:
Probably using some hashing to make sure it won't happen.
Oh, I think i got it now:
even if the patch would succeed, you still dont want to patch the updated file to avoid unpredictable software behaviour (?)
I can't help on that, sorry, but by personal experience, no cat has ever been killed by a successfull patch, even if the file to patch was updated.
If the context is sufficiently wrong, patch will warn you and refuses to modify the file.

I want a bigger context. The file.

ayekat, Trilby: In my case, I can't merge upstream. I tried, in most cases I failed. The dev don't want to.
Do you have tools to manage all those packages? To track patches, track failed patching and so on?
It was suggested that I use git with custom files and bash scripts to track these patches but maybe you know a tool that does this?

kokoko3k · 2021-08-23 17:32:43

Tharbad wrote:

kokoko3k wrote:
Tharbad wrote:
Probably using some hashing to make sure it won't happen.
Oh, I think i got it now:
even if the patch would succeed, you still dont want to patch the updated file to avoid unpredictable software behaviour (?)
I can't help on that, sorry, but by personal experience, no cat has ever been killed by a successfull patch, even if the file to patch was updated.
If the context is sufficiently wrong, patch will warn you and refuses to modify the file.
I want a bigger context. The file.

Just to be clear, since you posted into "Arch discussion" subforum, how is your question specifically related to Arch?
I assumed we were talking about managing Arch software packages/PKGBUILDs.
Is this the case or what?
How do you plan to install the software you want to patch?

The answer to your problem could be as simple as writing a shell script with an array of full paths to file to patch and with their md5/whatever and a simple check on them.
if they match, copy the patched file over no need to even use a patch command.
I'm having an hard time trying to understand what the problem is, sorry.

Last edited by kokoko3k (2021-08-23 17:37:58)

kokoko3k · 2021-08-23 17:38:58

Tharbad wrote:

kokoko3k wrote:
Oh, I think i got it now:
even if the patch would succeed, you still dont want to patch the updated file to avoid unpredictable software behaviour (?)
I can't help on that, sorry, but by personal experience, no cat has ever been killed by a successfull patch, even if the file to patch was updated.
If the context is sufficiently wrong, patch will warn you and refuses to modify the file.
I want a bigger context. The file.

Just to be clear, since you posted into "Arch discussion" subforum, how is your question specifically related to Arch?
I assumed we were talking about managing Arch software packages/PKGBUILDs.
Is this the case or what?
How do you plan to install the software you want to patch?

The answer to your problem could be as simple as writing a shell script with an array of full paths to files to patch and with their md5/whatever and a simple check on them.
if they match, copy the patched file over them.
You dont even need to even use a patch command.
I'm having an hard time trying to understand what the problem is, sorry.

Last edited by kokoko3k (2021-08-23 17:40:24)

Tharbad · 2021-08-23 17:49:48

kokoko3k wrote:

Tharbad wrote:
kokoko3k wrote:
Oh, I think i got it now:
even if the patch would succeed, you still dont want to patch the updated file to avoid unpredictable software behaviour (?)
I can't help on that, sorry, but by personal experience, no cat has ever been killed by a successfull patch, even if the file to patch was updated.
If the context is sufficiently wrong, patch will warn you and refuses to modify the file.
I want a bigger context. The file.
Just to be clear, since you posted into "Arch discussion" subforum, how is your question specifically related to Arch?
I assumed we were talking about managing Arch software packages/PKGBUILDs.
Is this the case or what?
How do you plan to install the software you want to patch?
The answer to your problem could be as simple as writing a shell script with an array of full paths to files to patch and with their md5/whatever and a simple check on them.
if they match, copy the patched file over them.
You dont even need to even use a patch command.
I'm having an hard time trying to understand what the problem is, sorry.

It's not a package but I want to get insight from the dev.

It wordpress plugins and themes not compatible with php 7.4 because wp minimum php version is 5.6.
Once I understand how manage it, all patches will be posted on gitlab/github under gpl2.

qinohe · 2021-08-23 18:09:13

You would completely ignore security, but, use a customrepo which holds your old PHP packages.
Only rebuild the customrepo if one of the packages fails to install - this would be easily scripted, array...

Obviously, you then need to rebuild that one failing package and hope your 'old' patch still works without problems and
rebuild the customrepo OC.

I don't use that many patched packages myself, but I have a few.
Mostly the patches work fine on the newer version of the file otherwise recreate the patch and move on...
I see no way to automate this further than the above.

Tharbad · 2021-08-23 18:32:40

qinohe wrote:

You would completely ignore security, but, use a customrepo which holds your old PHP packages.
Only rebuild the customrepo if one of the packages fails to install - this would be easily scripted, array...
Obviously, you then need to rebuild that one failing package and hope your 'old' patch still works without problems and
rebuild the customrepo OC.
I don't use that many patched packages myself, but I have a few.
Mostly the patches work fine on the newer version of the file otherwise recreate the patch and move on...
I see no way to automate this further than the above.

Why it's ignoring security?

qinohe · 2021-08-23 18:39:27

Because upstream still paches 5.6PHP.
So, all your PHP packages are in a customrepo and you choose to only rebuild packages when problems emerge, that will be ignoring security.
It would work, though, it wouldn't be my choice. That's why patching is work!

twelveeighty · 2021-08-23 19:10:01

qinohe wrote:

Because upstream still paches 5.6PHP.

Is that correct? Wasn't end of support Jan 2019 for 5.6?

Tharbad · 2021-08-23 19:12:38

qinohe wrote:

Because upstream still paches 5.6PHP.
So, all your PHP packages are in a customrepo and you choose to only rebuild packages when problems emerge, that will be ignoring security.
It would work, though, it wouldn't be my choice. That's why patching is work!

php 5.6 is dead: https://www.php.net/supported-versions.php

If it was alive I wouldn't have this problem.

Edit: That's half true. I also fix sec problems (usually lack of sanitation) but those are usually welcomed upstream.

Last edited by Tharbad (2021-08-23 19:17:17)

qinohe · 2021-08-23 19:30:53

Yep, I didn't even notice that, anyway using a customrepo the way I mentioned don't change the way patching works.

Arch Linux

#1 2021-08-22 19:03:51

Patch management

#2 2021-08-22 19:43:11

Re: Patch management

#3 2021-08-22 20:15:49

Re: Patch management

#4 2021-08-22 20:31:50

Re: Patch management

#5 2021-08-22 20:50:35

Re: Patch management

#6 2021-08-22 21:06:31

Re: Patch management

#7 2021-08-23 15:58:57

Re: Patch management

#8 2021-08-23 17:32:43

Re: Patch management

#9 2021-08-23 17:38:58

Re: Patch management

#10 2021-08-23 17:49:48

Re: Patch management

#11 2021-08-23 18:09:13

Re: Patch management

#12 2021-08-23 18:32:40

Re: Patch management

#13 2021-08-23 18:39:27

Re: Patch management

#14 2021-08-23 19:10:01

Re: Patch management

#15 2021-08-23 19:12:38

Re: Patch management

#16 2021-08-23 19:30:53

Re: Patch management

Board footer