Re: Reorganization of KDE chapter

"Bruce Dubbs" ([email protected] via blfs-dev Mailing List) <[email protected]>
Newsgroups gmane.linux.lfs.beyond.devel
Message-ID <[email protected]>
On 1/16/25 04:08, Pierre Labastie ([email protected] via blfs-dev Mailing List) 
wrote:
> Le mercredi 15 janvier 2025 à 22:53 +0100, Rainer Fiebig a écrit :
>> 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.
> 
> 
> 
> Nope: three in frameworks, two in plasma. But ok, since the only
> persons who answered were against the change, I'll retire it...
> 
> I submitted it because having two places in the book where the same
> package can be built is not clear IMO, specially because the two builds
> don't place the package in the same directory (and don't tell me
> warnings are enough to prevent building them twice: if a user begins
> with LXQt, then builds KDE, there is no warning in KDE... But this is
> how the book is and changing things that have been there for a while,
> even if they are troublesome in some case, is always difficult, because
> people are used to it.

Pierre, I do appreciate your ideas.  It's good to consider alternatives.

I would like to make a couple of corrections about lxqt.  Actually there are 7 kde 
packages:
   kwindowsystem-6.9.0 for lxqt  kf6
   kconfig-6.9.0 for lxqt        kf6
   solid-6.9.1 for lxqt          kf6
   kidletime-6.9.0 for lxqt      kf6
   kwayland-6.2.4 for lxqt       plasma
   libkscreen-6.2.4 for lxqt     plasma
   layer-shell-qt-6.2.4 for lxqt plasma

Building packages twice should not cause any problems as long as they are installed 
into the same location.  The extra build time is not terribly significant (about 2.5 
SBU).  The problem occurs if different versions are installed in different locations.

If the user installs kf6/plasma before lxqt, then there should be no issue.  In the 
lxqt pages the books says:  "This package is extracted from the KF6 set of packages. 
If KDE Frameworks-6.9.0 is built, do NOT also build this package as presented here."

The same for plasma packages.

In that case the kde packages, whether in /usr or /opt will work fine.  What needs to 
be avoided is installing the packages above in both /usr and /opt.

There is also a potential problem with installing twice.  If for example 
kf6/kconfig-6.9.0 is installed in /opt and then the user installs kconfig-6.10.0, 
then the results are quite problematic.  I would be very surprised if both DEs worked 
properly.

I will say from an LFS developer's point of view, lxqt makes things difficult.  For 
release I build two relatively complete systems.  One with KDE in /opt and another 
without KDE but installing lxqt in /usr.

   -- Bruce

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.