rolling release?
 

Hi everyone,

I have made my own auto build scripts for LFS-7.1 (I haven't upgraded to 7.2 yet) with some changes, the biggest is systemd instead of sysvinit.

The build process and LFS is working great (from what I can tell) I just need to prepeare a partition and mount it to /mnt/lfs and then go to /usr/src and run make world and my scripts build LFS to /mnt/lfs.

I have always preapered two / partitions, one is not used until I build a new LFS release then I use that one and change booting to that partition instead of the old.

Now I have bought a SSD and because I have a 13" laptop I can't have more drives thus the space on the drive isn't enough to "waste" space on a second partition. So I have been looking into rolling release, I do know what it is but I have no idea how to implement it. When I google it all I get is info on what it is not how to implement it.

I do know I need to start with rebuilding the toolchain. But what is the fastest "correct" way of doing this? the best way I guess is the LFS way (clean install on second partition).

I wish I knew what you need to know. I don't. Sorry. I can tell that you've read the chapter in the book on Package Management and upgrade issues. And you know that some things can have a newer version simply re-installed, but other things will bust stuff all over the place doing that. I'm one who decided to rebuild the whole system about every six months. I keep my kernel reasonably up-to-date, but things like glibc and gcc and so on are in for the duration in my BLFS systems.

To me, creating scripts requires as much effort as just going ahead and installing the system by hand following the book. And deploying that system to other partitions or machines is a simple tar procedure. I do admit that it is fascinating to sit there and watch a script go, but I've never been convinced that it saves time or effort when all is said and done.

Well, regarding rolling release. I do know What it is, but I don't know How to implement it. But I think I continue on my old route. The same route you have with re-installing the system every 6 month or something.

I made the scripts because I like to do stuff like that. So now my build process is like this
Then I go and do something else, usually I leave it building when I sleep. And when I come back I have to do something like this
Now that is very few commands compared to manually build the LFS, Well sure I can do a .tar backup very fast. But when I want to update I only have to update the build script for the packages that have changed, then I run the above commands and I have a newer LFS built.

Please don't misunderstand this. I'm not arguing. We're just talking here. Right? If not, if you're angry, then I apologize for interfering and won't return here after this. At least I legitimately bumped your thread. Maybe somebody with the rolling release idea will see its activity and come here.

You're completely entitled to do what you want. I just think you missed my point about time and effort. I've done the scripts, too. So I am well aware of the difference. But when you compared running your script to rebuilding the whole system, you didn't include the development time for the script. That is what I meant by a script not saving time or effort. It didn't for me anyway.

And regarding updates, it is often the case that more than package version numbers is involved. Often the dependency requirements change too. Often that leads to new seds in the commands to fix things. The order of packages changes sometimes. And so on. What I mean is that maintaining a script over time may not be so easy to do. If it were, I think everybody here would be building with scripts. But it doesn't appear to be the case by my observation of the topics. Not only that, and I may by wrong about this, but the ALFS projects seem to be long dormant when I look at them. The current and development versions of nALFS have dates no later than 2006. And for jhalfs, the current version is 2009 and there is no development version. But maybe that is normal and people are still using those. That I don't know.

Anyway, good luck with your project ideas and happy scripting. I, for one, will be interested to find out how it turns out. So long.

The point of scripting the build ( I do ) is that it is much easier to correct/spot mistakes if you make a mistake typing a command at the beginning somewhere it may be difficult to remember and/or track down a typo some hours/days later.
Also if you make a mistake you don't have to redo all that typing ( which may then include other typos ).
I know copying/pasting does prevent some mistakes but not if you accidentally skip a bit of the book, I would suggest pasting your commands into a script or at least a text file so that you can check later what you may have done wrong or missed.
Of course it's different strokes for different folks I guess, the world would be dull if we all did the same things ( and these forums would be redundant 'cos we'd all be using windows! ).