Page MenuHomeLubuntu Development

consider minimal install
Open, NormalPublic

Description

There's a highly lauded feature introduced in 18.04 in ubiquity that allows for a minimal installation, which is more or less what [lubuntu-core](https://help.ubuntu.com/community/Lubuntu/Documentation/MinimalInstall) is.

It has been asked many times if Lubuntu was going to support this. This certainly was a relevant question for 18.04, but since we've switched to calamares and 18.04's official support has ended, perhaps not.

On the other hand, there is an advantage to being able to install the system without a network connection which the mini.iso cannot do. Also, the way it is exposed in ubiquity, it's very easy for the user. There's no having to figure everything out.

There is one other caveat, though: this feature as we know it is a temporary solution. The new "Next Generation" installer subiquity is supposed to replace ubiquity and will supposedly be more flexible, allowing for such things as a minimal install. Whether or not the way we see it today is the way it's going to be is anyone's guess.

That said, it would nice if we could figure something out, or at least decide whether or not we're going to bother.

Related Objects

Event Timeline

wxl triaged this task as Normal priority.Apr 14 2019, 3:19 AM
wxl created this task.

The new "Next Generation" installer subiquity is supposed to replace ubiquity

That's incorrect, as of last time I checked with Foundations. It was meant to replace the ncurses debian-installer frontend.

I agree with this task, though.

Well, regardless of whether or not it's going to be subiquity (the "s" supposedly stands for server), there is supposedly a new installer in the works.

Anyways, talk to me about potentially implementing this in Calamares and the pros and cons therein.

So upstream has now implemented the packagechooser module which I think should fix this. @kc2bez would you be interested in both pulling down 3.2.12 and exploring this possibility? To be more clear there's two goals:

  1. provide a way to do a minimal install, i.e. what lubuntu-core is rather than lubuntu-desktop
  2. at least start providing some options to choose between different browsers, etc.
In T58#1941, @wxl wrote:

So upstream has now implemented the packagechooser module which I think should fix this. @kc2bez would you be interested in both pulling down 3.2.12 and exploring this possibility? To be more clear there's two goals:

  1. provide a way to do a minimal install, i.e. what lubuntu-core is rather than lubuntu-desktop
  2. at least start providing some options to choose between different browsers, etc.

I have started looking into this a little. First, I think # 2 is very obtainable and it is the sort of thing the packagechooser is designed for, small amount of choices and changes.
One thing that I haven't really found yet is package removal which make # 1 more possible.
Another note, there are currently about 4 upstream issues that have been opened up for the new packagechooser so we may want to let it mature a bit. I do plan to keep it in the close sights as it has a great deal of potential. Meanwhile, if anyone else wants to kick the tires, the version in unstable/ci should have the packagechooser in it, you just need to add the appropriate config files.

@kc2bez what I was thinking with 1 is that we would have two collections: one full, one minimal. You just pick between them. Isn't that just the same as having two office suites to choose from? Honestly I think 1 is the more urgent item and should be the focus of this task. If it's not attainable for this release, we should boot this.

Since Dan has what I think is the most sense of this, I'm giving this to him.

In T58#2017, @wxl wrote:

Since Dan has what I think is the most sense of this, I'm giving this to him.

I will keep working on this but we may need to bump it. I will keep you posted.

We must have this for 20.04, IMHO. If we have to drop for 19.10, it's ok.

We should bounce this to 20.04 IMHO. There are some issues still upstream, this one impacts us. Then there is this, this and this.
To top it off, I can't see where you can remove packages, only add them, we'd have to tinker on that too. As much as I would like to see it, I don't think it is ready for us at this time.

Unfortunately shuffling to 20.10.

A minimal could be used. In Ubuntu Cinnamon, to keep the architectures there and keep the repo clean (so there isn't the same file over and over of the same file with -(arch), we use a script that has:

  1. File for the info: desktop, desktop-recommends, etc.
  2. The script that goes through the list of Archs, and then replicates the file with that suffix.

Here Germinate can build.

  1. The clean script would allow these extra archs to be removed.

A similar path might want to be taken-view Ubuntu Cinnamon Remix's meta commit for more.

For such a lightweight DE, this is pretty essential.

Things werent clear with the seed-but I think for now in Calamares Minimal should be welcomed-or a package chooser of some sort before stepping further.

When I originally wrote this, I really hadn't looked into the mechanisms employed in the Ubuntu minimal install. I'm not sure why I'm shocked to find this, but it looks like it's a simple matter of package removal.

That said, assuming packagechooser is in good shape (most of the bugs mentioned seem resolved), I think all we need for the minimal install is removal. The thing I don't understand is how packagechooser (which seems to simply set global variables) and packages (which actually does the installing/removing of packages) work together.

P.S. Check out the end of that commit message. Multiple layered rootfs sounds like it would be the perfect solution for us. I wonder how that works in Subiquity?

In T58#4060, @wxl wrote:

When I originally wrote this, I really hadn't looked into the mechanisms employed in the Ubuntu minimal install. I'm not sure why I'm shocked to find this, but it looks like it's a simple matter of package removal.

That said, assuming packagechooser is in good shape (most of the bugs mentioned seem resolved), I think all we need for the minimal install is removal. The thing I don't understand is how packagechooser (which seems to simply set global variables) and packages (which actually does the installing/removing of packages) work together.

Your comment about packagechooser and packages is spot on. There isn't really an upstream module that pairs with packagechooser. The distributions that have employed packagechooser have their own removal module, and isn't distribution agnostic. At first thought, removing packages sounds like a great shell task but there is no way to glean the global variable saved earlier in the process in a shell. Next up is Python and I have a stab at a hacky script that seems to work. It is a WIP and there are a few things that I would like to work out.
A little pseudo code:

Grab the choice presented in packagechooser , "Minimal Install" or no selection.

If minimal -
apt-get purge -qy the list of packages.
I think I should add apt-get autoremove probably -qyto clean out unnecessary dependencies.

If no selection -
skip on to the next job

Since we share Calamares with all of the Ubuntu flavors how to package this might be a thing we need to discuss at some point. The other complete module (automirror) we have is utilized by everyone. I guess we can put it in with all the other modules and if no one calls it in the settings.conf it shouldn't be an issue. I might've just sorted that << out by typing it.

Here is a list of packages I have to remove:

pkglist = ['qlipper',
                 'kcalc',
                 'qtpass',
                 'ark',
                 '2048-qt',
                 'quassel',
                 'skanlite',
                 'transmission-qt',
                 'noblenote',
                 'trojita',
                 'qpdfview',
                 'vlc',
                 'k3b',
                 'libreoffice-*']

I'll entertain revisions to that list ^ but it seems like a good start.

Let me know if I am off base at all here.

In T58#4080, @kc2bez wrote:

There isn't really an upstream module that pairs with packagechooser. The distributions that have employed packagechooser have their own removal module, and isn't distribution agnostic.

Is this something that's been talked about implementing in a more agnostic way?

At first thought, removing packages sounds like a great shell task but there is no way to glean the global variable saved earlier in the process in a shell.

A contextual process acts based on global variables but is otherwise like a shell process, so I think that's what we'd need to do.

That said, I'm not against the Python but I think the more we simplify things the better and I find Python sometimes makes things more complicated.

apt-get purge -qy the list of packages.
I think I should add apt-get autoremove probably -qyto clean out unnecessary dependencies.

Agreed. Perhaps it's a little aggressive, but I say implement it and we can tweak it later.

Since we share Calamares with all of the Ubuntu flavors how to package this might be a thing we need to discuss at some point. I might've just sorted that << out by typing it.

Yes, I think you did ;)

I'll entertain revisions to that list ^ but it seems like a good start.

As above, let's get it implemented (or at least tested) with what we have. We can deal with the fine details later.

In T58#4082, @wxl wrote:
In T58#4080, @kc2bez wrote:

Is this something that's been talked about implementing in a more agnostic way?

Not really. Sort of the opposite actually. There was talk of dropping packagechooser altogether but there are folks using it so it stays. Most distros are using NetInstall.

At first thought, removing packages sounds like a great shell task but there is no way to glean the global variable saved earlier in the process in a shell.

A contextual process acts based on global variables but is otherwise like a shell process, so I think that's what we'd need to do.

That said, I'm not against the Python but I think the more we simplify things the better and I find Python sometimes makes things more complicated.

Yeah, fair enough. This doesn't seem too bad. It allows for a possible framework for future additions. We might be able to roll the current packages module in too thereby dropping the number of modules back down.

apt-get purge -qy the list of packages.
I think I should add apt-get autoremove probably -qyto clean out unnecessary dependencies.

Agreed. Perhaps it's a little aggressive, but I say implement it and we can tweak it later.

Sounds good.

I'll entertain revisions to that list ^ but it seems like a good start.

As above, let's get it implemented (or at least tested) with what we have. We can deal with the fine details later.

I will try to get something to test soon.