Package Management for LFS

[Jeremy Huntwork]

LFS and BLFS need to harmonize their suggestions for package management. It has been generally agreed that this is a topic for LFS, since if a user decides to use some form of PM, he/she will want to do so starting in LFS chapter 6.

See the above URL for a related thread.

We may also want to look further at Tushar's fake root installation approach for LFS.

[chris@…]

I do agree LFS and BLFS need to be consistent as far as package management, but I think that what is said in BLFS (no specific package management scheme recommended or used in LFS) is what should stay.

[Matthew Burgess]

Having re-read the discussion about this, I think that the way we should handle this is to a) remove the recommendation of the specific package manager we currently have in 6.1 and b) Put the paragraph pertaining to package management in a Note box.

If BLFS are happy to continue maintaining the meat of the Package Management information, I'd prefer it to stay there for the time being at least. We've already set a precedent by referring to Cracklib from Shadow, so asking folks to go and read BLFS at this point isn't too onerous, I don't think.

The only other concern I have is that the final note on that page says:

"The remainder of this book is to be performed while logged in as user root and no longer as user lfs. Also, double check that $LFS is set."

That may well conflict with whatever package management method a user chooses. Do we assume our users are clueful enough that they don't need this conflict explicitly spelled out to them?

[Jeremy Huntwork]

(In reply to comment #2)

Having re-read the discussion about this, I think that the way we should handle this is to a) remove the recommendation of the specific package manager we currently have in 6.1 and b) Put the paragraph pertaining to package management in a Note box.

Matt, I respectfully disagree. I think LFS should deal with it, and do it justice. BLFS shouldn't have to worry about package management, but provide generic instructions a user can adapt to their decision concerning package management. Considering PM should start in chapter 6 of LFS, LFS is where it should be handled.

If we move what is in BLFS to LFS, with a good review of the text to make sure it fits its placement in LFS, I think we'd be handling it much better than a note box referencing a user to BLFS. This is a far bigger issue than one library to link in to a particular package - the Cracklib comparison seems a different situation to me.

[jim@…]

If we are to follow LSB standards, we need to include RPM.

​http://lsbbook.gforge.freestandards.org/package.html#RPM

[Matthew Burgess]

(In reply to comment #3)

If we move what is in BLFS to LFS, with a good review of the text to make sure it fits its placement in LFS, I think we'd be handling it much better than a note box referencing a user to BLFS.

Well, I wouldn't call it a "good" review, necessarily, but having read it, I think the information that is in BLFS is ideally suited to LFS, and can be applied to LFS as-is (after BLFS editor's agreement is sought, of course).

This is a far bigger issue than one library to link in to a particular package - the Cracklib comparison seems a different situation to me.

Yes, on second thoughts I agree.

So, here's the revised plan of attack for this bug then:

a) Incorporate BLFS' package management text in a new "6.2 Package Management" section b) Move the Note from the bottom of 6.1 over to the bottom of the new 6.2 section. c) Remove the final paragraph in 6.1 ("To keep track of...") as it is now catered far more fully in the new 6.2 section

(In reply to comment #4)

If we are to follow LSB standards, we need to include RPM.

​http://lsbbook.gforge.freestandards.org/package.html#RPM

Nope, we're not going to recommend any particular package manager for folks. We'll leave it up to them to choose the technique best suited to their needs.

[Jeremy Huntwork]

(In reply to comment #5)

Well, I wouldn't call it a "good" review, necessarily, but having read it, I think the information that is in BLFS is ideally suited to LFS, and can be applied to LFS as-is (after BLFS editor's agreement is sought, of course).

Er, no I meant we should review the text that is in BLFS before we put it into LFS. But, seeing that you've done that, the point is moot now. :)

[Jeremy Huntwork]

(In reply to comment #4)

If we are to follow LSB standards, we need to include RPM.

​http://lsbbook.gforge.freestandards.org/package.html#RPM

Nope, we're not going to recommend any particular package manager for folks. We'll leave it up to them to choose the technique best suited to their needs.

We could always list that link and note LSB's standards without recommending a particular path. Would that be an acceptable option?

[Matthew Burgess]

(In reply to comment #7)

(In reply to comment #4)

If we are to follow LSB standards, we need to include RPM.

​http://lsbbook.gforge.freestandards.org/package.html#RPM

Nope, we're not going to recommend any particular package manager for folks. We'll leave it up to them to choose the technique best suited to their needs.

We could always list that link and note LSB's standards without recommending a particular path. Would that be an acceptable option?

Heh, my first thought on this was "no, no, definitely not!". However, RPM is already mentioned in the BLFS text, so why not change the sentence it appears in to read: "Examples of package managers that follow this approach are RPM (required by the LSB [hyperlink to the LSB spec]), pkg-utils, Debian's apt, and Gentoo's Portage system".

[Jeremy Huntwork]

(In reply to comment #8)

Heh, my first thought on this was "no, no, definitely not!". However, RPM is already mentioned in the BLFS text, so why not change the sentence it appears in to read: "Examples of package managers that follow this approach are RPM (required by the LSB [hyperlink to the LSB spec]), pkg-utils, Debian's apt, and Gentoo's Portage system".

Looks good to me.