| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
Am 16.01.25 um 16:38 schrieb Bruce Dubbs ([email protected] via
blfs-dev Mailing List):
> 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.
A radical, probably unpopular but effective solution would be to drop
LXQT from the book. Just to have mentioned it.
Rainer
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page