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.

Somewhat related to this, upstream is working on allowing the user to choose sets of packages.

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.

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.

@kc2bez what's the word here?

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.

Bounced. Keep an eye on it.

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.

3. 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.

I've opened Pull Request #1 on GitHub:
https://github.com/lubuntu-team/lubuntu-meta-packaging/pull/1

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.

I have an updated calamares-settings-ubuntu in my PPA that is ready for some testing on Hirsute. I have gone through it once and it does what it is supposed to do for me. I encourage others to test it too.
To have a minimal install select the minimal install package in the list when you get to the package chooser section. For a standard installation just click next.
TODO:
Some screenshot/image to signify a minimal install for package chooser.
Some better logging, and probably better feedback too. It would be good to print the package that the module is currently removing probably.

Future TODO:
Roll the current packages module into the "chooser_companion" module so that we can resolve T152 and T34 and reduce needed modules.

Tested this on Lenovo V14 IIL i3-1005G1,8GB,256GB M2NVMe SSD box updating Hirsute daily 08-02-2021 . Booted UEFI+secure .

All went well and looks good. Booting and login both very fast - lightning speed.

Intend to run further tests on other boxes.

2 further tests - Acer E3 -111 and InWin BL641 (VirtualBox) and all worked well - no errors encountered.

(Virtual machine on an i5, 16 GB RAM, onboard Intel HD Graphics) #VirtualBox 6.1

Tested minimal install and tested full install. Both worked just fine at my end. Congrats - and maybe backport it for Focal.

Lenovo X230i i3-3120M,8GB,Intel HD graphics,WiFi,Ethernet,Bluetooth,320GB hd

Tested minimal and full install - Hirsute daily 2021-02-18 ISO -as in early tests no errors encountered.

Checked memory and disk usage -
Min install 367Mb used of 7774Mb total - disk space 272.5 Gb free of 291,1 Gb
Full install 390Mb used of 7774Mb total - disk space 271.7 Gb free of 291.1 Gb