[blfs-dev] Building LXQT

Bruce Dubbs bruce.dubbs at gmail.com
Sun Sep 27 10:00:11 PDT 2015

Pierre Labastie wrote:
> On 27/09/2015 15:12, Fernando de Oliveira wrote:
>> Em 27-09-2015 09:48, Pierre Labastie escreveu:
>>> On 27/09/2015 13:14, Fernando de Oliveira wrote:
>>>> Em 27-09-2015 07:14, Pierre Labastie escreveu:
>>>>> Hi,
>>>>> I've started adapting my automation scripts to build LXQT. I think I might
>>>>> find a few places where there is a problem for extracting the instructions,
>>>>> which are not visible in the rendered book. I'd like to be able to change what
>>>>> is needed for my scripts to work (when it does not change the rendered book)
>>>>> without informing the list before, since I guess others would be weakly
>>>>> concerned...
>>>>> Also, the id attribute in the chapter tag in lxqt/desktop.xml should be
>>>>> changed to something less generic than "desktop", because it has to be unique
>>>>> inside the whole book... I'll change it to "lxqt-desktop", in the attribute
>>>>> and at any place it is xref-erred.
>>>>> Please do not hesitate to comment.
>>>>> Pierre
>>>> Actually, the xml name could also be changed I've seen generic names
>>>> (most my fault) such as
>>>> ./postlfs/config/config.xml
>>>> ./kde/core/config.xml
>>>> ./lxde/desktop/desktop.xml
>>>> ./lxqt/desktop/desktop.xml
>>>> ./lxqt/desktop/pre-install.xml
>>>> ./lxqt/desktop/post-install.xml
>>>> ./x/installing/installing.xml
>>> I am not sure there is a need to change the xml names: their whole path is
>>> _not_ generic. Problem with the id's is that they have to be unique inside the
>>> whole book, and they have no context.
>>> Pierre
>> I do have other problems with files having the same name. So I am sure
>> "there is a need to change the xml names" even if "their whole path is
>> _not_ generic". No, I wont't write them.
>> Normally, I warite things not only because I had an idea, but something
>> was needed or a difficulty or problem hit me.
>> But with this reply, I can safely say: everybody agrees other than
>> Fernando being an update machine, everything else Fernando thinks only
>> matters to himself.
>> Bye.
> I just wrote "I am not sure". It means exactly that there may be a problem,
> which I do not know. And your post did not tell what the problem was. I
> certainly would be happy to learn, and I am confident you could teach me a
> lot. Anyway nobody writes, says or thinks what you write in the 3rd paragraph.

I agree that file names, both xml and html should be specific enough to 
identify them uniquely without relying on the path.  If an editor makes 
such a a change to make things clear, I see no problem as long as the 
book renders properly.  I don't think notice is required. Just explain 
in the commit comments.

For internal issues like an id, the same applies.  More descriptive 
names are good, but I generally-do-not-like-very-long-names.  It's best 
to limit names to under about 15 characters if possible.  Of course 
global names like an id can be too short.  Unique, well known short 
names like gdb are ok, but packages like BerkeleyDB use just db and that 
is too short/non-unique.

   -- Bruce

More information about the blfs-dev mailing list