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"..... 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. 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. -- A bientôt =========================================================== Jean-Marc Pigeon E-Mail: [email protected] SAFE Inc. Phone: (514) 493-4280 Clement, 'a kiss solution' to get rid of SPAM (at last) Clement' Home base <"http://www.clement.safe.ca";> ===========================================================
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
