| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
Le mercredi 15 janvier 2025 à 12:21 -0600, Bruce Dubbs a écrit :
> On 1/15/25 04:03, Pierre Labastie ([email protected] via blfs-
> dev Mailing List)
> wrote:
> > Hi all,
> > I've created a git branch plabs/no-build-twice with the aim of
> > preventing the possibility of building some kf6/plasma packages
> > twice.
> > This is the case for kf6/plasma packages used in lxqt (which are
> > both
> > in the lxqt chapter and on the kf6 or plasma pages), and of plasma-
> > activities* packages that are both in the kf-apps chapter and in
> > plasma.
> > This branch also makes a more conventional layout for the kde
> > introduction. The main changes are:
> > - creating a "KDE packages used in other environment" chapter,
> > containing the packages formerly in KDE intro and the packages
> > needed
> > for LXQt
> > - removing the corresponding packages from LXQt
> > - have KDE-frameworks or plasma depend on the already built
> > packages,
> > and comment them out in the .md5 file
> >
> > I am not sure whether it is acceptable for the other editors and
> > users,
> > so please let me know. But this change makes jhalfs life much
> > easier
> > (I'm not sure I could make jhalfs work with current book,
> > actually).
>
> Building kf6/plasma is complicated. When I first set it up I wanted
> to give the user
> the option to install in /usr or /opt. Installing in /opt makes for
> a clean
> environment for upgrades or re-installation. It also allows the user
> to change
> versions by changing a single symlink. For example.
>
> ln -sh kf6-6.9.0 /opt/kf6
>
> Right now on my development system I have:
>
> drwxr-xr-x 8 root root 4096 Aug 27 12:17 kf6-6.5.0
> drwxr-xr-x 8 root root 4096 Nov 8 15:06 kf6-6.8.0
> drwxr-xr-x 8 root root 4096 Dec 13 13:16 kf6-6.9.0
>
> and can use any of them for testing.
>
> When we added lxqt it became more complicated. That DE requires
> packages from both
> kf6 and plasma. We generally install lxqt in /usr. There is a big
> warning in the
> kf6/plasma pages in lxqt to not install them if the associated
> package is already
> installed. What we definitely want to avoid is building the same
> package in two
> different locations.
>
> I did check out plabs/no-build-twice and it always installs the kde
> packages in /usr.
Sorry, that is not true, but I agree it makes a mixture of /usr and
/opt:
- Common packages are installed in /usr (as are already extra-cmake-
pacakges and breeze-icons)
- Packages built on the main KF6 and plasma pages are in /opt (as are
kf6 applications).
> This completely removes the original intent to give the user the
> option of
> installing in /opt. It also makes building kf6/plasma more
> complicated for the user.
Note that ECM version changes for each version of KF6, but we build it
in /usr (same for breeze-icons). So changing the link in /opt does not
change those.
I don't see more complication, just more commented out lines, but there
are several already. ANd a few more modules to be built before the main
pages, but we already have several too.
>
> I'll also note that in a recent change we need to build plasma-
> activities{,-stats}
> from plasma in order to build okular, but in my mind building those
> twice is no big
> deal. After all we build freetype and other circular dependencies
> twice.
>
> I'm not sure how to handle this in alfs. In some places we have
> dependencies of nasm
> or yasm. I don't know how this is handled in alfs.
Build both: those are short builds anyway.
>
> Right now if the user chooses to install lxqt before kf6/plasma, the
> the /opt is no
> longer available. When automating, I think it is important for the
> user to know the
> options and the rationale behind the decision.
Not sure I understand what you mean. Problem is a user may build LXQt
and without knowing he or she would decide later to build KDE. In this
case the decision might not be the same as if the use knows that he or
she will be building both before beginning.
The current proposal allows to get the same layout in both cases.
>
> I do not like the current proposal for the above reasons, but am
> willing to consider
> other options.
Of course, I am willing too: that's why I opened a discussion!
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page