#1777 closed defect (wontfix)
XFS instructions/LFS dependencies
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | BOOK | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description (last modified by )
The installation instructions for XFS mention that it requires e2fsprogs. However, since BLFS assumes that all BLFS users have a complete base LFS system, this note should be removed.
Change History (11)
comment:1 by , 18 years ago
| Description: | modified (diff) |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:2 by , 18 years ago
| Version: | ~CVS → a-SVN |
|---|
comment:4 by , 18 years ago
Since you're the only one who's responded, I'll assume that their silence means agreement. Change will go in later today.
comment:5 by , 18 years ago
It is just my opinion, but it has always been traditional that things are discussed on -dev, then implemented. Not very many subscribe, nor read, -book and we can't expect folks to be browsing the bugs either.
It has simply always been expected that if there is something to be discussed about the book, it is in -dev.
I am commenting about this as you say "since you're the only one"... and I don't remember a -dev conversation about it.
comment:6 by , 18 years ago
I don't object to having UUID as an optional dependency, as long as it is in the book. Reason: This dependency is not trivial. The required (because of the generic fsck program) e2fsprogs package already ships libuuid, and I want to have the exact list of files to be overwritten by UUID.
comment:7 by , 18 years ago
Well, I'm certainly not going to add UUID to the book since we assume you've built LFS and then you would have libuuid. I really don't care if this is a note or an optional dependency. I just wanted to close this bug.
I'm going to close this as wontfix unless someone really wants it changed. Randy, you haven't said anything yet here or on the list. No opinion?
comment:8 by , 18 years ago
My opinion (since you asked) is that the book is perfectly fine the way it is. There is a note explaining that if the package was not installed in LFS that you need to install it or another package.
I don't see what the bug is all about, nor do I see that it should be a bug. I don't think these packages should be added as dependencies, as they are expected to be installed.
The note simply serves as a support-protection device and a courtesy to users who may not have installed the package.
I'm for doing absolutely nothing other than closing the bug.
comment:9 by , 18 years ago
Tbe bug is just about consistency in the BLFS book, and what its policy should be as far as what LFS packages you're assumed to have.
I don't really see the point about the note being a "support-protection device" - there are several packages in LFS that some people might not install, but don't have notes about them in BLFS (autotools, for example). I would think that the assumption would be that anyone who knows enough to deviate from the LFS book would also know enough to understand the implications.
comment:10 by , 18 years ago
| Priority: | high → low |
|---|---|
| Resolution: | → wontfix |
| Status: | assigned → closed |
The note in question is informational. It is not a formal "dependency."
Yes, we do expect users to install all the packages in LFS, but in this case the note merely indicates that there is an alternative. We leave it to the user to determine any side-effects that may have unintended consequences.
Closing as wontfix.
Does anyone care about this? My thought is changing UUID to an Optional Dependency with a note that it is an alternative to E2fsprogs. This would be similar to the note about libedit in Bc.