about patch descriptions

Gerard Beekmans gerard at linuxfromscratch.org
Fri Oct 18 14:02:31 PDT 2002


On October 18, 2002 02:51 pm, Anderson Lizardo Gomes wrote:
> Hi,
>
> I'm "synthetizing" my questions that appeared before I read the threads
> "patch description missing for gcc" and "gcc 3.2 patches". I think that
> the learning side of the LFS Book is very important. In my case, I
> learned lot of new things just by reading the book. But one thing that I
> never understand (yet) is why we should apply that patches. I know that
> sometimes it's because some packages has broken code, but... how this
> broken code is corrected? I don't know almost anything about C/C++, so
> just reading the patch don't help very much.
>
> There are some descriptions in the book, but they explain what problems
> are resolved, no HOW they are resolved. If I search in mailing list

The problem is: if you don't know any C, the "HOW" problems are resolved won't 
make much sense. You'd see things like "yeah we changed the X variable to Y 
minus the Z randomized variable to make function D more compatible with IEEE 
spec 185.15081.15". 

Ok that's total rubish but get the idea? It'll sound exactly like that to 
people who don't know C and C++ so they only get more confused. That's why we 
currently simply stick with "it fixes a compile problem when using this Glibc 
version or that GCC version". Yes it's vague but at least most people will 
get the idea of what's done. The HOW part is for the programmers can can just 
as easily view the patch in a pager or editor and see what parts of the code 
was changed.

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list