Opened 8 months ago

Closed 8 months ago

#5338 closed enhancement (fixed)

Add a new page "Updating an LFS system"

Reported by: Bruce Dubbs Owned by: lfs-book
Priority: normal Milestone: 12.1
Component: Book Version: git
Severity: normal Keywords:
Cc:

Description

The page should be in the Introduction part, probably between Changelog and Resources. It should describe issues when upgrading packages on an existing system.

Change History (8)

comment:1 by Xi Ruoyao, 8 months ago

There is already section 8.2.1 "Upgrading Issue".

in reply to:  1 comment:2 by pierre, 8 months ago

Replying to Xi Ruoyao:

There is already section 8.2.1 "Upgrading Issue".

Hmm, maybe misplaced too? Several of the described issues there have nothing to do with package management, but the title of section 8.2 is "Package Management"...

comment:3 by pierre, 8 months ago

In some way, isn't it a too advanced subject for LFS? This might rather go into Beyond LFS...

Or maybe it is something for the "The End" chapter?

comment:4 by Bruce Dubbs, 8 months ago

I agree about 8.2.1 being misplaced. That's not what most users think about when discussing 'Package Management'.

I wanted to put something relatively short early in the book for users to be aware of upgrading issues. Generally I think more attention is paid by new users to the early parts of the book.

I don't think BLFS is appropriate if a user is upgrading an LFS package.

I also want a place to move the commented out section in the beginning of the whatsnew xml.

in reply to:  4 comment:5 by pierre, 8 months ago

Replying to Bruce Dubbs:

I agree about 8.2.1 being misplaced. That's not what most users think about when discussing 'Package Management'.

I wanted to put something relatively short early in the book for users to be aware of upgrading issues. Generally I think more attention is paid by new users to the early parts of the book.

On the other hand, upgrading is not something users are likely to do while working through the book. If the page about upgrading is at the beginning of the book, it is probable users will have forgotten it when they reach the end...

I don't think BLFS is appropriate if a user is upgrading an LFS package.

My point is that upgrading is not something that comes during the course of the LFS book, but rather after completing it. I agree that a page about upgrading LFS may get unnoticed in BLFS, though.

I also want a place to move the commented out section in the beginning of the whatsnew xml.

I think that at some place, early in the book, we should have something like "don't change book version while building LFS", and only that! Then somewhere close to the end of the book, tell all the problems about upgrading, including problems with reusing scripts... People reusing scripts (which means they have already built at least part of the book) don't read the beginning of the book again!

BTW, I think the paragraph about --disable-fixincludes can completely go away now: it was a change between 11.3 and 12.0 version, but it won't change again (unless we decide to, in which case it should go into changelog). And if adding --disable-fixincludes has an effect on upgrading, it is to remove some pitfalls rather than introducing issues.

comment:6 by Bruce Dubbs, 8 months ago

I think your points are valid. For the caution in whatsnew, what do you think about putting it into 2.3. Building LFS in Stages?

Should the Package Management page be moved? If so, where should it go?

comment:7 by pierre, 8 months ago

The "package management" page at the beginning of chapter 8 can be considered to be at the right place, since it is at this point that users should set up PM if they desire to. But actually, the question is "for whom?". For first time builders, I think it is better to stick to the book and not do anything out of what is written. For "rebuilders", the place to talk about possible additions is a question: I don't think rebuilders would read the beginning of the book again, or of any chapter...

comment:8 by Bruce Dubbs, 8 months ago

Resolution: fixed
Status: newclosed

Upon consideration, I moved the caution to General Compilation Instructions.

Fixed at commit 1ec60f1daf34b0021d903405899a217e4d214b93

Note: See TracTickets for help on using tickets.