Diff Detail
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 8934 Build 9325: arc lint + arc unit
Event Timeline
I disagree with this. I intentionally did not support EXTRA_PATCHES because it's quite often wrong. Extra patches are switched by many things (ARCH, OSVERSION, etc) and there's no guarantee that they will be generated, or generated correctly. More often than not, they will simply be deleted.
For this reason, intentionally, EXTRA_PATCHES is not covered by make makepatch and trying to do support is not a good idea IMO.
I really did do a lot of thinking about it.
Well, for example, for the dns/bind9* ports, there is a patch activated by an option, having to rename it each time I update the port so that it gets regenerated (and rename it back so that I can see if there were changes) is a pain. With this patch, it gets regenerated just fine.
It may not be the perfect solution that would regenerate extra patches depending on OSVERSION or other weird stuff, but it can regenerate patches that are actually applied, so it helps.
Is there something inherently wrong, technically, with my patch ?
yes, it's conceptually flawed.
Another COMMON example:
regular patch "A" modifies file "B".
There's also extra patch "C" that modifies file "B"
When you run makepatch, it combines changes from A and C into a single patch (assuming extra patch was applied).
This is an unacceptable outcome.
There are too many common situations like this to support extra patches.
In my opinion, it's too dangerous and extra patches, which should be rare, must continue to be hand-edited. (or better yet, changed to code using equivalent of C macros so regular patches can be used, if possible)
Sure, if there are two patches that patch the same file, it won't work, but there are ports that do this without the help of EXTRA_PATCHES.
So, if I remove all the non technical things you say, my patch is good, right ?
it's always been a conceptual discussion, not a technical one.
The "multiple patches affect the same file" issue wrt to extra patches cannot be ignored or hand-waved away responsibly in my opinion.
- It's a common situation. This is one the reasons to have extra-patches, because of multiple incompatible changes to the same file based on situation
- Regular patches with this problem are usually due to compound patches or pulling individual patches from git repo that happen to patch the same file. The maintainer in this case should manually combine or again, hand edit.
I'm disagreeing with this on a conceptual basis. I don't want extra patches contaminating regular patches (or getting deleted in error, which is another common result). I would rather they simple be excluded from the process (as they are currently) and handled manually.
- Regular patches with this problem are usually due to compound patches or pulling individual patches from git repo that happen to patch the same file. The maintainer in this case should manually combine or again, hand edit.
So, in this case, you agree that there is to be hand editing anyway. I don't see what it will change to also regenerate EXTRA_PATCHES.
I'm running out of ways to express myself.
current situation:
makepatch perfectly regenerates regular patches.
extra-patches untouched, user will have to manually handle them, but there are no surprises
proposed change:
makepatch can produce corrupted regular patches and the extra patches disappear (either merged or deleted). Both are problems. It's also hard to untangle.
current >> proposed.
use has option to rename extra patch to regular patch name, run makepatch, and then rename back though.