Alexander E. Patrakov wrote:
> Please subtract the number that want to use the LiveCD to cover LFS bugs,
> don't
> realize the inherent incompatibility of LFS with 64-bit hosts (IMHO, the fact
> that LFS doesn't mention it counts as a bug), or don't know how to apt-get
> install build-essential.
How in the world am I supposed to do that? Do you know the skill-level
of every individual that commented in every list? Even if I add your
vote to bring the 'drop it party' up to 3 (I could also add mine in
favor of keeping the project, which I don't need to) and I stick to only
people whose skill level I know, the majority are still voting to keep
the project.
As an aside, I fully disagree with your inflexible stance on who is
'allowed' to use either LFS or the LiveCD, or whose opinion on either
product counts. The prerequisites stated in LFS are _suggested
guidelines_. Nowhere does it say that people that don't meet those
prerequisites are not free to use LFS or the CD, or that their
experience with it is invalid.
If someone who had just encountered a PC 2 weeks ago stumbled onto LFS,
managed to work their way through it and came out the other end
successful, I'd applaud them! Sure, they wouldn't have approached LFS
the way it was intended, but if they learned something, the main goal
has been reached. Obviously they are intelligent and determined enough,
and very likely they will continue to learn and grow. Therefore, their
opinion and feedback is just as valuable.
And think of the reasons why those guidelines exist in the first place!
First and foremost, isn't it because we want the reader to be successful
in their experience? After that objective, IMHO, comes the secondary
purpose that we as developers can't be responsible for the experience of
every person who decides to start down the LFS path. There is nothing
that requires us to provide more support to those who should have read
more first. Far better for you to ignore them then to make judgment
calls on who is 'allowed' to use the product or express their opinion
about it.
> Then we need a procedure to deal with feature requests ("reject outright"
> also
> counts as a procedure). Also we need a procedure to determine what counts as
> a
> feature request and what doesn't (e.g., what to do with net-firmware,
> scsi-firmware and the numerous kernel patches and extra drivers for new
> hardware?)
Agreed.
> This is incompatible with the "strictly adhere to LFS" goal, because LFS has
> no
> package management except "rebuild everything once a day". Note that I make
> no
> statement about the relative merit of these two incompatible goals.
I suppose so. Although, the way I was perceiving it:
* The configure and make arguments do not change so there is no
difference in the binaries produced
* The install arguments do not change so the binary locations are the same
* All we really do is package up and log
Isn't it still adhering strictly enough to LFS to count? Granted, this
may not meet what is truly considered package management in a distro
sense, but it would still ease development, and help in allowing further
customization.
>> * Add an LFS-style document to the project that teaches how to create a
>> LiveCD from scratch.
>
> IMHO, this would line up with the rest of the project nicely, and doesn't
> exclude actually providing some binary CD.
Yes, this is turning out to be a good suggestion, I believe.
>> * Devise methods for users to more easily provide feedback and make it
>> easier to contribute as a whole.
>
> This also should include stating what kind of feedback is needed. So far,
> there
> were only "please add this package" requests, borderline cases like "old
> laptops
> with the OnTrack disk manager doen't see the partitions with libata" (solved
> by
> adding kpartx) and a few bug reports.
Agreed.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
