| Newsgroups |
gmane.linux.lfs.beyond.support |
| Message-ID |
<[email protected]> |
Am 16.08.25 um 06:01 schrieb Randy McMurchy ([email protected] via
blfs-support Mailing List):
> On 8/15/2025 5:38 PM, Joe Locash ([email protected] via blfs-support
> Mailing List) wrote:
>
>> libqtxdg isn't a required dependency of libnotify.
>
> Yes, it is. At least as far as I'm concerned. You guys are not seeing
> the picture here. I look at recommended runtime requirements as packages
> that must be built. In my mind, recommended dependencies are the same as
> required dependencies. It was that way when I was an active BLFS editor
> and reading the quote below reaffirms the way I think now. Here's what
> the book says about dependencies:
>
> "Required Dependencies
>
> <snip> If a dependency is said to be “runtime,” it is not needed for
> building the package, **but only to use it after installation**.
>
> Recommended Dependencies
>
> If a recommended dependency is not said to be “runtime,” package
> installation instructions **assume it is installed**. <snip> A
> recommended “runtime” dependency does not need to be installed before
> building the package, but **must** be built afterwards for running the
> package with reasonable capabilities."
>
> The **emphasis** in the quote above is mine.
>
> Both required and recommended descriptions about runtime dependencies
> infer that the package is going to be required sooner or later. My
> approach is sooner. If it's going to be required down the line, I just
> go ahead and install the package. I install runtime dependencies as I
> see them in the book. It should not matter to BLFS editors when a
> package is installed or what it will be used for. The fundamental
> purpose of BLFS back in my day was to expand the knowledge gaining
> process of LFS while creating a system that fulfills the user's needs.
> The important LFS philosophy of "Your Way" should always be respected
> and endorsed. Presenting facts and information about the packages is as
> important as creating instructions to provide a stable build.
>
> Now, with that in mind I'd like to try and explain my thought process to
> y'all. I do not yet know what type of desktop environment I'm going to
> use (or if I will even want to go there actually) as I used KDE in the
> past but ending up launching FireFox and Thunderbird from the command
> line more often than not. I've been working on terminal type interfaces
> since MS-DOS was born and the earlier days of HP-UX, Solaris, AIX, SCO
> and even older operating systems. My first job in the IT industry was
> centered around HP MPE running on an HP-3000 machine that had external
> hard disks as big as washing machines. Working from a text based
> terminal type environment is just second nature to me.
>
> Now to the issue at hand. I have a need for the WebKitGTK package. It
> should not matter to the BLFS team what a user/reader wants or needs the
> package for, only that he/she wants to build it. The name of the package
> and the brief description in the book leads one to believe that the
> package probably provides useful functionality, which in itself might be
> enough to install it. It has a recommended runtime dependency of
> GeoClue, which also sounds like it could be useful. So I decide to build
> it.
>
> Geoclue has a recommended dependency of libnotify. So it must be built.
> libnotify has three required runtime dependencies, and because I don't
> yet know what the eventual purpose of this system is, I decide to
> install all three of them. So that brings me to lxqt-notificationd. To
> build this package I must install liblxqt. To build liblxqt I must
> install libqtxdg.
If what Joe Locash said is correct, then any of the three
run-time-dependencies for libnotify would suffice. I've already made a
suggestion that would make that clearer. And perhaps this should even
be amended by a note that the two desktop-environment-associated
packages would have to be built in the build-order required for that
desktop-environment. And I think that other similar cases should be
handled accordingly.
Rainer
>
> Here's where it got fun. After ensuring that all the dependencies were
> installed, I tried to build libqtxdg and it failed due to the reason
> this thread exists. So you see that there really is a need to be a bit
> more creative when listing dependencies. There's never too much
> information if it's factual and pertinent. Just a simple parenthetical
> blurb like (required as you may not be building the LXQt desktop in the
> order prescribed by BLFS) after the lxqt2-build-tools required
> dependency would be useful information.
>
>
>> You're probably trying to build lxqt-notifcationd and getting sucked
>> down the rabbit hole.
>
> If that's what you want to call it. My approach is apparently different
> than how the BLFS team perceives the book should be used/read. Bruce did
> mention that it wouldn't hurt to list the required package in the
> libqtxdg instructions, and I agree.
>
>
>> The required runtime dependencies for libnotify are
>> notification-daemon, xfce4-notifyd, or lxqt-notificationd. An
>> emphasis should be placed on the or.
>
> The or should not matter one bit. What if a user wanted to test out LXQt
> and Xfce side-by-side on the same machine?
>
>
>> Since your doing this for geoclue you're probably building gnome. Just
>> build notification-daemon and you should be fine.
>
> But what if I want to build Gnome, LXQt, and XFCE all on the system some
> time in the future. I like to know that required and recommended runtime
> dependencies are built for all the packages I install. Perhaps that's
> just me being a tad bit anal in my package building process. Old habit
> that stems from my time on the BLFS team. I always tried to have as many
> dependencies installed on my test systems as possible, as that provides
> better confidence that there won't be package breakage on some
> user/reader down the road.
>
> If you've got this far, I appreciate your patience reading my rant. It
> brings back old memories.
>
>
--
http://lists.linuxfromscratch.org/sympa/info/blfs-support
Unsubscribe: See the above information page