The more we discuss it, the more PM becomes a focal point. I agree with Greg Schafer in that the actual choice of PM is a user's choice in the end and shouldn't matter.
About all we should attempt to do is inform the user of all the main stream and (perhaps) some of the not-so-mainstream options out there. We need a clearly defined list of pros, cons and technical explanations plus their limitations of each viable choice - all the information that a user needs to make an informed decision while keeping in mind that some of these programs may never have been used (or heard of) before. So we can't assume a basic working understanding of the programs. Having said that, we will probably get to a scenario where we need to settle on something we will be using ourselves for the LFS project. For instance, the LFS server itself will eventually be outfitted with one of the results of this process. This wouldn't be an endorsement, but will probably be perceived as such - "if the LFS developers use implementation X on the LFS server and to develop the LFS project itself with, then I should probably use it as well." One could consider embarking on a mission to make all the PM options talk to each other so you can mix and match what PM you use at any given time - you can switch from deb to rpm to something else on the same system on-the-fly. That would be an interesting challenge in itself. ----- I don't think any one person can provide this kind of information. We tend to specialize in our favourites at the cost of knowing the ins and outs of other alternatives. Alexander started a thread about an RPM Proof Of Concept. I quickly glanced at it and it seems an installation HOWTO, not including the information I mentioned above that we need more than the installation itself right now. If you feel you can talk about a potential PM candidate for LFS, please write up a document that outlines the following: - it's strengths and weaknesses - why it's better than other candidates - why it's worse than other candidates - what it takes to integrate it in the LFS book * not looking for installation instructions. Just explain the impact and changes that will be required for successful use - what it likely is not able to do for its users - how well it can deal with matters such as conflict resolution and dependency handling ----- When all this information is collected, we can discuss (no point in doing this prematurely) how to move forward - namely how to redo the LFS book (or actually move away from having it be a book form). That's a discussion for much later. Let's get the individual components more clearly documented. Then we can discuss later how to pull it together once we know what we're dealing with. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
