I would agree that Debian packaging is unnecessarily complicated. The raw stuff is tedious, so various wrappers have been created. In the wild you see a mixture of wrappers and lower level packaging, making everything more complicated for the occasional user.

I started with Debian (not as a packager, but just as a technical user who occasionally wants to do his own stuff). Years later I was forced to use rpm and was suprised that things could be so straight-forward. Yet years later I was forced to look at Arch and was suprised again: Hey, you can understand all of it just in a couple of hours.

Accumulated experience might result in a slightly biased perception. But I still believe the described gradient exists.

I can't say I agree with that conclusion, if you're just applying a patch then you don't need to edit the low level packaging. It doesn't affect the occasional user at all.

To be honest, you still do need to grok the difference between native and quilt packages, and, in case of the latter, know that you need to put your patches into `debian/patches/` instead of directly modifying the source tree. And if you started by cloning the packaging from a git repo, you may need to know what pristine-tar is as well.

A well-written tutorial will explain that to you quickly, but there's definitely more friction than with PKGBUILD files where you can pretty much just look at the contents of the file and edit it directly without second thoughts.

The difficulty of figuring out exactly what you need to do is part of the problem. It's hard to shake the feeling that you don't really grok the build system.

But in any case it's never been as easy as just running that one command for me. Actual example from my bash history:

    $ apt source packagename
    $ vim path/to/broken/file.c
    $ dpkg-buildpackage

Now I get an error: "aborting due to unexpected upstream changes".

    $ dpkg-source --commit

Make a changelog entry for the changes you made

    $ dpkg-buildpackage

This fails with an inscrutable error "dpkg-buildpackage: error: failed to sign .dsc file"

If you know what you're doing you realize that you can just ignore this error, it doesn't affect the built package. If you don't, you have to search around and then build it again with

    $ dpkg-buildpackage -uc

So it's not, like, the worst thing in the world but it doesn't go out of its way to be intuitive either. It's hard to find good help on what to do (the man pages are arguably too detailed to be useful to people who just want to make small changes), and hopefully you didn't follow a rabbit trail with debuild.

What package and how complex is it?

I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.

When you say making a debian package is easy I want to know what kind of project it is you have experience packaging, like what type of assets has it got, what technologies does it use. How many languages, how many dependencies, how is it linked? That sort of thing

This is just for arbitrary autotools, cmake and meson projects using any language supported by those build systems. The sizes and dependencies vary. I don't really see it being much harder, the debian developer documentation is really convoluted but that's a different problem.

makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.

The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.