Re: Reorganization of KDE chapter

Am 15.01.25 um 19:08 schrieb Pierre Labastie ([email protected]
via blfs-dev Mailing List):
> Le mercredi 15 janvier 2025 à 17:13 +0100, Rainer Fiebig a écrit :
>> Am 15.01.25 um 16:02 schrieb Rahul Chandra
>> ([email protected] via
>> blfs-dev Mailing List):
>>> On 2025-01-15 07:58, Rainer Fiebig wrote:
>>>
>>>> Sorry, but from my perspective as a user this doesn't seem to be
>>>> a good
>>>> idea.  If I understand correctly, it would complicate and
>>>> fragment a
>>>> coherent and proven KDE-build-sequence and thus make life (even)
>>>> harder
>>>> for users.  I'm not against reducing redundancy, though.
>>>>
>>>
>>> If we call it kf6-minimal and kf6-additional I could see it as okay
>>> and
>>> not **that** confusing to the user.
>> At least one user _is_ confused already. ;)
>>
>> I really cant't see any benefit for users from this and I think that
>> the
>> changes would be made for the wrong reason (jhalfs).  KDE-Frameworks
>> is
>> an entity that can and IMO should be built in one go and not one part
>> here and another part there.  Complicating and fragmenting the
>> process
>> surely wouldn't help users.
> 
> It is already fragmented: breeze-icons in the "icons" chapter and
> extra-cmake-modules in the KDE introduction chapter. This just adds
> three others that would be built in the KDE introduction chapter. Note
Why three?  If I counted correctly, five FW-packages are used in LXQT:
- kwindowsystem
- kconfig
- solid
- kidletime
- kwayland

That would be five additional out-commented packages in the FW-md5 file.
 That wouldn't make it look more pretty.  And at least one additional
explanation would be necessary in "About Commented Out Packages".

> also that with the current book, if a user wants to build both LXQt and
> KDE (in this order), instructions for KF6 and plasma have to be
> modified exactly in the way I propose! and if somebody builds okular
> before plasma, instructions for plasma have to be modified to remove
> the plasma-activities* modules...
> I agree that for somebody building only one of the DE's and building
> kf6 applications after plasma, what I propose is slightly more
> complicated (but not that much since the modules that would be built
> before would be grouped in only one chapter).
It would not only be more complicated but also mean a more fragmented
build-procedure for packages that now can be built in one pass.

> 
> Actually, I should maybe not have put so much emphasis on jhalfs (but
> as the jhalfs maintainer, I'm a little biased): separating modules that
> may be common to several environments from the main kf6/plasma build
> makes the book clearer IMO.
I doubt that what you have in mind would make the book clearer.  I think
the opposite would be the case.  Sorry, but splitting up something that
formerly was a unit simply can't result in anything "clearer".

> 
> Also I think that rendering the book for this branch and reading it
> would help making one's mind better than by just reading my mail, which
> does not give all the details (they are in the commit messages and in
> the rendered book itself).
Well, may be.  But I think my imagination is good enough to get an idea
of what the affected chapters would look like if you go ahead with your
plan.  And frankly: I don't like what I see.  But as I said: just my two
cents. ;)

> 
> 
>>
>>>
>>>> In my view, jhalfs should not be a primary reason for significant
>>>> changes of the books.
> 
> Well, I use jhalfs for testing the book. This is useful in several
> cases that are not picked up, and speciallly for detecting missing
> dependencies...
As I see it, the books' primary mission still is to help an interested
audience get a better understanding of the inner workings of a modern
Linux operating system.  And as useful as jhalfs may be for you and
other power-users: with respect to that mission, jhalfs seems rather
tangential.  Again: just my opinion.  After all, you asked for it. ;)

Rainer

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page