On Thu, Nov 01, 2018 at 02:47:11PM -0400, Jean-Marc Pigeon via blfs-dev wrote:
>
> 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.
True. In this week's lwn.net the link to reproduceable builds
mentions rustc.
> - As package is huge (2Gig), compilation time is out
> of control.
If you are lucky, it will use all your cores. If you are unlucky,
it won't. The purpose of it was as a safer language, to build for
all supported architectures, in the expectation that the end-users
would take binary downloads.
> - No way to compile without being on the net.
Search the archives - somebody mentioned (in the past few weeks, or
months) that we should produce a list of what it downloaded, and
gave some details of how to use pre-downloaded versions. But that
is a maintenance overhead for which, like lxqt, we have nobody
willing to do it.
My personal other annoyance with it is that it needs multiple
versions of some of the crates, and also the continuing changes will
eventually mean that a current rust cannot build some older
application.
> - Its a "package deal" coming with own basic libraries set
> (doubling the bugs surface)
Unsure about that - they claim to be more secure, but it is a few
years too soon to judge if that claim is true.
> - 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...).
Dunno about RPMs, but in ~/.cargo I have 534MB (downloaded cargo
files, apparently extracted contents, index) and (from one test
install in /opt) 310MB of libraries.
> - 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.
>
Personally, I'm not overjoyed about having to use many of the
packages in BLFS to built a modern desktop. But the package
developers make the choices.
> 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.
>
It's nothing to do with building fedora, or debian-unstable, it's
all about having a *supported* browser (firefox) which gets
fairly-timely updates as new vulnerabilities are discovered.
Packages such as librsvg then decided to use rust.
I say "fairly-timely" because some vulnerabilities only become
known at a release after the fix has been well-soaked in
firefox-beta, whereas others cause point updates.
Compare that to qtwebengine where chromium vulneabiities get picked
up, but a new release seems to always wait until a Qt point release
is due.
And don't get me started on the attititude of the developers of the
firefox forks (if you really want to know, look at the archives of
this list for my comment on basilisk).
ĸen
--
Is it about a bicycle ?
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
