#22611 closed enhancement (wontfix)
Move muparser to General Libraries
| Reported by: | zeckma | Owned by: | blfs-book |
|---|---|---|---|
| Priority: | normal | Milestone: | 13.0 |
| Component: | BOOK | Version: | git |
| Severity: | medium | Keywords: | |
| Cc: |
Description
When updating a package in SLFS, I noticed it now required muparser. I didn't notice muparser was in BLFS since I would have expected it to be in genlib. Instead, it's in the LXQt section.
It was originally put in LXQt since no other packages need muparser in BLFS. But this sorta thing isn't treated the same way consistently. A lot of the time, packages are put in their proper category that they best belong to regardless what they are used by. For instance, let's say AppStream had its own chapter, and an update needed libfyaml but libfyaml is only used by AppStream, it shouldn't matter. libfyaml is still a general library and should be put in genlib. muparser falls in the same case, especially so since other packages outside of BLFS use it.
It's misleading to call muparser a LXQt component, it's a completely unrelated library. That's why I believe moving muparser to genlib is for the best. I was told that when muparser got added, there was an effort to put it in genlib but got denied because of the LXQt thing. We should do some future-proofing and move it to genlib, to be less misleading and more clear.
I can do this if approved.
Change History (3)
comment:1 by , 9 months ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:2 by , 9 months ago
The problem is that VTE makes sense where it is, because it's tied to GNOME directly. muparser isn't tied to LXQt in any way. Plus, moving muparser early avoids heartbreak because we will probably have to do it down the line anyway. I'd rather us be set up for success instead of correcting a mistake that was made in the past that we knew about. And again, it's misleading for it to be in the LXQt section.
What I'm arguing for is completely unrelated packages getting moved to sections that the packages actually match, while packages that are welcome with the sections they reside in stay. Context matters here.
NACK. We only want to consider this if there is another package in BLFS that needs it. The lxqt chapter is meant to be worked through in sequence, like LFS. Moving a package because it might be needed in the future is premature.
It would also set a precedent that I'd prefer not to set. For instance vte is in the gnome/platform directory, but is referenced in xfce4-terminal, gemu, and gnome-terminal.