Re: libcupsfilters: mupdf not "Required"

On Tue, 2026-02-03 at 16:25 +0100, Maurice van der Stee wrote:
> 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 ?

Sure. It is 3 AM, your phone just wake you up.
You have a critical system crash, hardware? attack?,
recovery time is critical (even if you have a backup system)...
You barely able to have the defective file system on-line
using something as sash.
Available (very basic) tools are: cat, ls, dd, grep....
and you want to know quickly when/which log stop recording,
and what was the last event recorded....
once you see/catch the problem, you can use basic
tools to repair...
doing all that while the phone is continuously
ringing (asking what about the problem!?!?)

Do you see the picture?

According my experience with systemd, I do
agree with Uwe Düffert behavior systemd description.

> 
> > 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, 

-- 
a bientôt

Jean-Marc Pigeon
SAFE Inc.

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