On 11/01/2018 01:47 PM, Jean-Marc Pigeon via blfs-dev wrote:
Hello,
I found lxqt-0.13 working very well within LFS-8.3, and
I think team should reconsider its decision about it.
Within a private email exchange with Bruce trying to make the point,
he told me "LXQ dependencies are cumbersome, I should consider
to look at XFCE...a lot easier".
Why not, if I found LXQT easy enough, XFCE should be a
"peace of cake".
It was true, was able to define 2 XFCE modules "spec file" every hour.
Until I reach xfce4-xkb-plugin, a very small module to
use none US keyboard....no big deal...
Well... as there is countries flags in "svg" format you
need librsvg, right....
librsvg need cargo (according designer, to be able to
easily set the compilation debug flag (?)), and cargo
is embedded with rustc...
Wohhh... I have seen Email with a subject as "I hate rustc".....
I don't remember if that came from me, but I at lest share the
sentiment. Unfortunately rust is required for the current firefox,
thunderbird, and librsvg packages.
Lets figure this out.
#metoo, "I hate rustc".
- 2 Build, hours apart won't give the same result, event
if it is the same version number.
- As package is huge (2Gig), compilation time is out
of control.
- No way to compile without being on the net.
- Its a "package deal" coming with own basic libraries set
(doubling the bugs surface)
- RPM file is near 600 Megs....
(600 Megs for a compiler???, some time ago, I designed a
YACC parser in UCSD-pascal, within the Apple-II 64kbyte memory,
and it was able to compile its own YACC definition and rebuild
itself..., come on, 600 Megs for compiler...).
- Rustc project seems to be a biological chimera between
C (language) and modula2 (units implementation and
standardization)
- I wonder if rustc is an experimentation or a "coding bad trip".
I (strongly) think rustc should be outcasted From Linux From Scratch.
Why?
I do not consider LFS as a tool to build a kind of Fedora Linux.
The LFS contribution is to define a path to build a Linux, that
path try to resolve dependencies and locks, exposing the
components layering... IMHO this is the real LFS project
contribution to the linux ecosystem.
LFS team have done great job about it.
So LFS project should keep a clean layering...
A 500Kbytes package as xfce4-xkb-plugin should NOT trigger
600 MBytes addition with it own standard libraries coming
from nowhere (according my understanding, as librsvg use cargo,
something (but not only) as basic regex (v0.6.2) was added....
what there is exactly within the package librsvg package then??...)
LFS should be a reference and give an "imprimatur" to good
Linux components (components with clear position with layers).
I will pursue xfce implementation to see where is the beef...
But, so fare, in term of implementation complexity, LXQT is
a lot easier than XFCE.
Nothing actually requires xfce4-xkb-plugin. If you are using a standard
US keyboard, you do not need it. I admit that we imply that it is
needed.
Another solution is to build an earlier version of librsvg (2.40.30)
that did not use rust.
-- Bruce
I know team use LXQt 0.11, but LXQT made progress and
designed a compilation/install process fitting perfectly
with LFS . In fact the whole LXQT package could be define
now within only one BLFS page.
What I found missing from LXQT is the menu editor,
as in gnome-2, to easily add panel components (drawer, widget, etc..)
I am looking to menulibre, but so fare result are not really here.
For those which want to play with LXQT within LFS-8.3
https://osukiss.safe.ca//downloads.php
My 2 cents.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
