| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
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
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).
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.
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).
>
> >
> > > 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...
> >
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page