it depends on the fix and the context of the code it touches. a one
liner in 2.6.26 may not necessarily have to become a 100 line, multi-file
fix in 2.6.16. look at 28d838cc4dfea980cb6eda0a7409cbf91889ca74 for an
example, that was trivial to backport to many kernel versions before.
also, if you can find a commercial distro whose kernel predates even
yours (i.e., yours is between mainline and a well maintained commercial
one) then you may not actually have such a big problem with backports
even for more complex fixes as you can peek at what the commercial guys
are doing.
in any case, you're answering a different question or i'm failing to see
the logical connection between 'irrelevant' and 'laborious'. basically you
said now that you don't provide security info because it's labourious to
backport fixes, or something like that. i'm afraid there's no such logical
connection. you also didn't answer the question about why you should not
make the life of people doing the actual backports (paid for, commercial,
whatever the trigger word for you is) easier.
and how does that imply that you should not mark security fixes as such?
remember, we're not discussing how backports are done in the world, but
why you're helping them by withholding security information. because if
you admit that you're not, then that's one less reason to withhold this
info.
cheers,
PaX Team
--
