You are not logged in.

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

Tharbad
Member
Registered: 2016-02-27
Posts: 260

Patch management

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.

Offline

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

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,206

Re: Patch management

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.


Help me to improve ssh-rdp !

Offline

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

Tharbad
Member
Registered: 2016-02-27
Posts: 260

Re: Patch management

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?

Offline

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

ayekat
Member
Registered: 2011-01-17
Posts: 1,462
Website

Re: Patch management

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.


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,747
Website

Re: Patch management

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.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

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

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,206

Re: Patch management

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)


Help me to improve ssh-rdp !

Offline

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

Tharbad
Member
Registered: 2016-02-27
Posts: 260

Re: Patch management

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?

Offline

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

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,206

Re: Patch management

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)


Help me to improve ssh-rdp !

Offline

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

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,206

Re: Patch management

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)


Help me to improve ssh-rdp !

Offline

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

Tharbad
Member
Registered: 2016-02-27
Posts: 260

Re: Patch management

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.

Offline

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

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,338

Re: Patch management

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.

Offline

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

Tharbad
Member
Registered: 2016-02-27
Posts: 260

Re: Patch management

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?

Offline

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

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,338

Re: Patch management

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!

Offline

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

twelveeighty
Member
From: Alberta, Canada
Registered: 2011-09-04
Posts: 847

Re: Patch management

qinohe wrote:

Because upstream still paches 5.6PHP.

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

Offline

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

Tharbad
Member
Registered: 2016-02-27
Posts: 260

Re: Patch management

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)

Offline

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

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,338

Re: Patch management

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

Offline

Board footer

Powered by FluxBB