Re: libcupsfilters: mupdf not "Required"

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.

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). 

systemd on the contrary hide everything (even logs).
This could be good for desktop market but linux market
is a server one. 

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.









> 
> I for one fully support the choosen direction, otherwise the project
> would soon be next to worthless, 

-- 
a bientôt

Jean-Marc Pigeon
SAFE Inc.

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