Re: libcupsfilters: mupdf not "Required"

On Tue, 2026-02-03 at 10:08 -0500, Jean-Marc Pigeon wrote:
> On Tue, 2026-02-03 at 15:10 +0100, Maurice van der Stee wrote:
> > On Tue, 2026-02-03 at 14:36 +0100, Rainer Fiebig wrote:
> > > Am 03.02.26 um 03:41 schrieb Uwe Düffert
> > > ([email protected] via
> > > blfs-dev Mailing List):
> > > > Hi,
> > > > 
> > > > On Mon, 2 Feb 2026, Rainer Fiebig wrote:
> > > > 
> > > > > I was just about restarting work on this when I read that
> > > > > bombshell-news
> > > > > about dropped support for SysV.  What an unfortunate and
> > > > > blatantly wrong
> > > > > decision!  Very disappointing and demotivating.
> > > > > 
> > > > > To me it seems pointless now to contribute to this project
> > > > > anymore.  So
> > > > > I drop out of this thread here.
> > > > I was hoping I could avoid the discussion, but at this point I
> > > > feel
> > > > I
> > > > should raise my voice too. I'm happily following *LFS in a way
> > > > "since
> > > > decades". I haven't contributed all that much, but I'm a huge
> > > > fan
> > > > of
> > > > "your system - your rules". So basically I'm build *my* system
> > > > and
> > > > really appreciate all your effort, teaching etc. to allow me to
> > > > do
> > > > that.
> > > > And I only contribute when I have the feeling that whatever I
> > > > found
> > > > out
> > > > about building my system could be ahead of or otherwise be
> > > > beneficial
> > > > for what you are doing "officially".
> > > > 
> > > > Guess it is rather save to say by now that I will *never*
> > > > switch
> > > > to
> > > > systemd either - as long as I can avoid it in any way. I can't
> > > > always -
> > > > in my company I have to deal with it, but it's burden! I
> > > > understand
> > > > the
> > > > theoretical benefit for "complex scanarios", but often it is
> > > > more
> > > > like
> > > > complicating instead of solving problems for me. Yes it is e.g.
> > > > "caring
> > > > about" magically restarting crashed services but may easily do
> > > > so
> > > > with
> > > > with wrong parameters or credentials. Which is way harder to
> > > > deal
> > > > with
> > > > than a just stuck or crashed service. That is something I can
> > > > deal
> > > > with,
> > > > maybe craft a maintenance cron job around it or something. But
> > > > that
> > > > may
> > > > well run into a race condition with systemd trying to do it
> > > > faster
> > > > but
> > > > intransparently and unfortunately wrong. Then the service seems
> > > > to
> > > > be
> > > > "well running" but it is disfunctional. Happened to me more
> > > > than
> > > > once...
> > > 
> > > Which boils down to "Systemd's distro - Systemd's rules". 
> > > Consequently,
> > > they should rename the project to "Systemd From Scratch".  And -
> > > while
> > > at it - the servers from "rivendell" to "mordor" and "anduin" to
> > > "morgulduin".
> > > 
> > > To me, the decision to drop SysV is all the more incomprehensible
> > > and
> > > inexcusable as LFS is primarily an educational project that
> > > intends
> > > "...to help you learn how a Linux system works from the inside
> > > out."
> > > With simple SysV as an init-system and some effort by the user,
> > > that
> > > was
> > > achievable.  With monstrous systemd this idea can be binned.  And
> > > so
> > > the
> > > "systemd-only LFS" will fail at its highest-ranking goal.
> > > 
> > > What users now (falsely) learn is that "... 1678 "C" files plus
> > > many
> > > data files." are needed to bring up and shut down a Linux-
> > > system. 
> > > And
> > > only later they may become aware that there would have been an
> > > alternative which needed only "... 22 C files ...plus about 50
> > > short
> > > bash scripts and data files." to do just the same job.  And at
> > > the
> > > same
> > > time let them have better control over their system.
> > > 
> > > > 
> > > > I'm very aware I may not be speaking for a majority, but *I*
> > > > would
> > > > prefer to drop support for GNOME and Plasma due to systemd in
> > > > favor
> > > > of
> > > > support for SysV or something... Your system, your rules, your
> > > > effort,
> > > 
> > > Exactly.  To drop the all too willing servants of systemd would
> > > also
> > > be
> > > the obvious alternative for lessening the workload.
> > > 
> > > > I'm not trying to convince anyone. That said: *LFS are not
> > > > loosing
> > > > me
> > > > that easily. I'm deviating from the book anyway, as long as it
> > > > helps me
> > > > - despite changed focus - the project is welcome.
> > > > 
> > > > @Rainer: Your contribution would not be pointless! Yeah, sure,
> > > > it
> > > > may
> > > 
> > > In my view, the decision to drop SysV means withholding a simple
> > > and
> > > proven core-element of a Linux-system from future LFS-users.  I
> > > consider
> > > this a disservice not only to them but to the Linux-ecosystem as
> > > a
> > > whole
> > > as this only fosters a systemd-monopoly.  And I will not support
> > > that.
> > > 
> > > I also think that needlessly sacrifycing simplicity and
> > > manageability
> > > for complexity and intrusiveness is generally not a good idea.
> > > 
> > > Rainer
> > > 
> > > 
> > > 
> > > > not meet your own quality standards anymore ("tested against
> > > > currect
> > > > offcial book"), but at least for me, it is welcome anyway.
> > > > Prominent
> > > > example: Thomas' multilib branch is not mainstream either, but
> > > > OUTSTANDING VALUABLE!!!
> > > > 
> > > > Keep up the good work, everybody!
> > > > Uwe
> > > > 
> > 
> > I had intended to stay out of this discussion. But this does it.
> > 
> > Raving about a non-existing monopoly. Do you have any idea of what
> > a
> > monopoly is ? Here there is an alternative. so there can be no
> > monopoly.
> > 
> > That other developers choose to use systemd is not something to
> > blame
> > systemd for. They are free to use it or not. But they choose to do
> > so
> > because of its merits.
> > 
> > The basic logic of system is not so different from sysv. Targets
> > compare to runlevels and service units to init scripts. If the
> > additional fucntionalaty would be inplemented sysv would also
> > vastly
> > increase in size. So what is the problem hete. It doesn't seem hard
> > to
> > grasp to me.
> > 
> > If you have nothing to say but this nonsense but shut up.
> Hmmm, this is rought.
> 
> As fare I can see, Sys-admin do not like systemd as it 
> (intend to) take precedence over sys-admin himself (this was
> well expressed few minutes ago in another thread) and
> do what it (systemd) want not what it should do.
> 

Can you give an example for this ?

> What I like with Unix (and linux) is the fact, in case
> of problem, to be able do go to Basic CLI command and
> pine point the problem.
> (unix basic concept: do one thing and
> do it very well). 

systemctl status <servie name> will tell you what went wrong.
systemctl --failed will tell you which units failed during boot.
> 
> systemd on the contrary hide everything (even logs).
> This could be good for desktop market but linux market
> is a server one. 

The logs can be seen using journalctl, nothing is hidden. 
Admittedly this has also a lot of functions which com in handy,
but if you just give journalctl -b you get all there is for the current
boot.

> About LFS, the whole idea behind the project, is
> to build a system from start, understanding each
> component and then switch to "my system, my rules, 
> then embracing systemd is quite acceptable.". 
>  
> so IMHO, systemd is contrary to genuine LFS purpose.
> 
> 
So don't try to grasp all of systemd at once, just the essentials being
the targets and service units. Maybe it would help to add a few lines
about this in LFS.
> 
> 
> > 
> > I for one fully support the choosen direction, otherwise the
> > project
> > would soon be next to worthless, 

-- 
=================================================
Maurice van der Stee

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page