Johannes,
Thank you for quick reply.
I am going to first try a variation of the approach you suggested where
I generate backports for Linux versions in the repo in ascending order
then have our Makefile detect user's version and install accordingly.
Wait, no, what? You don't need to detect the user's version or anything.
Ah, yes! Ok, wow. Sorry. Things are finally adding up... ¬‿¬
No no, misunderstanding here I think. You don't need anything granular
at all, *all* your users should be able to use a *single* current
backports-based package.
The granularity question only comes in when you say have a user who
reports that something doesn't work. Now what, how do you get them to
e.g. bisect? Right now you have a git tree they can normally bisect in.
Now, if you
- release backports tarballs for them to use, or
- commit the output of backports into a git tree for them to use
*then* you get into the granularity question, which ends up being a
trade-off between what's effectively bisectability (you don't really
need to care about the history, after all, it's preserved upstream), and
effort on your end to generate (and test) them all.
Right, yes.
After that, our Makefile and/or scripts it coordinates will have to
detect the user version, then cd into that package, and install it
properly.
No, you should just give them the output of backports (gentree.py)
directly, it does all this.
I am suspending any upstream commit history shenanigans for a
later point as making sure the driver is performant and in-line with the
up-to-date wireless stack.
OK, so then you just need to release a single tarball effectively.
Whether as a git branch or a literal tarball is pretty much irrelevant.
Ok, I now understand.
I think because of the way I was trying to do things before I was
failing to see how radically backports could simplify the task in many
ways. The approach I have been using is far away from this way of doing
things.
I am going to get started now.
Again, thank you for your patience and help.
Thanks,
Brian Witte
