MX Linux Forum

It seems that none of the pre-installed packages show up in "user installed packages".
Also flatpacks don't show up either.
I wonder if there's a way to tweak the "user installed packages" app to make it show all installed packages?
To me, that would be far more useful than how it currently functions.
It would be nice to have tabs for "all installed packages", "user installed packages" and maybe some other tabs such as "flatpacks" and "downloaded packages"; with the option to input a path for the downloaded packages for re-inetallation.
Then you could give the user the option to un-tick individual packages or entire tabs/sections.

IMO this would fulfill the presumed aim of "user installed packages" much better; i.e. making the process of upgrading from one major version to another as seamless as possible.

P.S. I also wonder if, in the long run, it wouldn't be better to roll this functionality into the MX package installer itself.
P.P.S - I hope this is classed as a "non-package feature request" - if this is not the right place to post this, please let me know. Many thanks.

justcosmic1 wrote: Mon Jan 15, 2024 8:45 am It seems that none of the pre-installed packages show up in "user installed packages".

That's the scope of this tool: To filter out all pre-installed packages and keep only those which have been added later. A new MX release ISO comes with a potentially different set of pre-installed packages.
So, the UIP tool may help user to re-install those packages which have been installed on top of the preintstalled ones. Flatpak was out of scope.

Maybe: Possibly consider - if UIP included all of the installed packages, it would no longer be a USER installed package list.

Will print a list of all packages by name only, no version number to a simple text file in your /home with the name all-packages.list

First of all, thank you for all the responses.

Yes I do realise that it would become a more global app and so calling it "installed packages" would then make sense.
As per my suggestion; having the option to only select the "user installed packages" tab would mean you could duplicate it's current functionality if you so desired.

However in real world use, I suspect that most people want to more or less reproduce their previous user environment and workflow as seamlessly as possible and then get on with using it. The fact that default applications may vary from one release to another, is even more reason for my suggested approach.
I guess the optimum way of doing that would be to actually be able to import a complete list into the installer itself; so that it would merge with packages to be installed by default: But that might be a more long term aim as I suspect it would be more work to do it that way.

However, you can see why I suggested that baking it into the MX package installer (and perhaps renaming it to "MX Package Manager") would make sense; as it would already show installed packages - including flatpacks.
Again, in the real world, people use flatpacks, downloaded .Deb files for applications not yet in the repositories (the very excellent WineGUI for example) and so on.
It would also be nice to have any "default packages" that the user had previously uninstalled or weren't installed, flagged for optional uninstall.
Regarding flatpacks - if MX Package installer can show the installed flatpacks, I don't understand what makes it such a hard thing to include; or why it should be beyond the scope of a more complete tool; but perhaps there are some technical reasons ?

I realise that my suggestion is to expand the scope of the "user installed packages" application beyond it's initial remit - as noted in the title of this feature request.
I also realise that it would probably be more complex to implement. As I have stated; I believe that in the long run, putting such a tool on the roadmap, would offer a much more complete solution for the purpose of upgrading.
I also have to recognise that major version upgrades don't come round super often; and can understand the reluctance to put resources into such an improvement.
In addition I recognise that some packages my no longer be supported or it may be advantageous to replace with recommended default applications: however I think that the user should be given the choice where ever possible.

Meanwhile I will, with thanks, try some of the command line options mentioned above; with the hope that some of them might perhaps in the future find their way into the application.
Lastly I want to say that I appreciate the current tool as it is (as I appreciate all the amazing MX tools) ; I can just see a potential for it which I sincerely hope developers will be inspired to pursue.

justcosmic1 wrote: Tue Jan 16, 2024 11:04 am... renaming it to "MX Package Manager" ...

In fact that's more correct cause it doesn't just install (say, like GDebi etc..)..

@justcosmic1 Sounds to me like you're suggesting a very labour intensive way to produce another cloning type tool, which offers exclusions for package & flatpacks. I'm not sure that complicating a very simple tool is the best way forward for this. I don't use flatpaks because they're bloated and heavy, so I can't attest to the process of checking what is installed.

Sufficient to say, flatpak -list is a command for that purpose. Whether or not that is installed, I don't know, but as it seems you are inclined to have them, maybe you can try it. You can send the output of any comnmand to a file, so a simple > name-of-file after the command would suffice to get that list into regular text form.
Keep in mind we have no control whatsoever over flatpak packaging or distribution and we do not lightly put up a notice about their use when users open the flatpacks tab in MXPI.

To produce a tool that does as you say, the onus would be on us to support it. Are you willing to take on that responsibility, to answer all the questions that come through the Forums and Social Media sites? Questions like why is flatpack xyz not available any more, or not working on my system, can you fix it?

Wouldn't our Snapshot tool not be the better choice for such a setup? In terms of efficiency, it reigns supreme in all points over a manual system and it works across multiple upgrades and snapshots, retaining the list of originally installed packages as at release so the UIP package can read from the original list.

Charlie Brown wrote: Tue Jan 16, 2024 11:29 am

justcosmic1 wrote: Tue Jan 16, 2024 11:04 am... renaming it to "MX Package Manager" ...

In fact that's more correct cause it doesn't just install (say, like GDebi etc..)..

Are we ready for such a title when the world at large would expect a distros custom built package manager to be a clumsy, slow, bloated web store, the types of which I find completely useless. The move towards package managers was intiially intended to provide a store type experience, championed by Ubuntu, but I hated it the first time I used it and have not changed in my opinion. I might be a dinosaur, but our MXPI title has gained ground with reviewers calling it refreshing to use a fast tool and I wonder if others will take a leaf from our book in the future.

Thanks again for responding.

Re Snapshots being the tool to rule them all - Yes it is amazing and perhaps the experience of using it inspired my feature request...

However as I understand it, the 2 tools have very distinct use cases/purposes (please correct me if I am wrong) :
Sanpshot creates a carbon copy/duplicate of your current version of MX;
User installed packages is intended to help you upgrade from one major version of MX to the next.
Is there is some functionality I have missed in Snapshot, or is the above assessment more or less correct ?

Looking closer at MXPI, I see that it already has a lot of the functionality I am asking for; it can already show you (on a per tab basis), the installed packages (including flatpacks).
It would seem easier to me, to build on what is already there and simply add the ability to export and import a list, rather than re-inventing the wheel so to speak.
I applaud wanting to keep things as lean as possible; but I don't think the poorly optimized/bloated PM's of the past should dictate the future and impede the addition of well thought out and implemented features that could streamline the user experience considerably, while not unduly compromising the light weight and responsive nature of the tool.

TBH when I first tried "user installed packages" I assumed it would actually list all 3rd party packages (at least optionally).
So I guess I had an expectation, (perhaps due to experiencing Snapshot) ; so for me, it fell short of what I had assumed it's purpose to be.
Don't wish to sound ungrateful - that's just my honest reaction as a user.

Much as I hear the argument about extra work, not just to implement such a feature, but also as you point out, to maintain it; I can't help but feel that if we had applied that thinking to Snapshot, or many of the other excellent MX tools; they wouldn't exist now.
So I guess it is a question of if the cost of maturing the concept which has been started with "user installed packages" is worth it for the end result.
As mentioned previously; I fully acknowledge that the main usefulness of this functionality is only at times like now, when we have a major new version.
Hence my suggestions to build additional functions into MXPI is partly to keep those man hour costs to a sensible level. But yes - I know it is easier to say than to do.

If in a couple of years time, when the next major Deb version drops, this functionality was present; it could make a major version upgrade as seamless as using Snapshot...
And IMHO that would be another outstanding aspect of MX that would be well worth the effort.

I forgot to say regarding flatpacks:
I really hear you on not wanting to encourage their use:
The sad reality is however that for many of us they are essential, as packages such as Obsidian for example are not available in the main repositories.

Re the naming thing...i.e. not wanting to call MXPI a package manager;
wouldn't that be a bit like not wanting to call a Ferrari a car, simply because there are these poorly made Fiats that are also called cars ?...

+1


Iirc (from Lubuntu and/or Mint) they use the words "Store" or "Center" which I dislike in general. (App. Store / Software Download Center or so)... However this is just a "Manager" as the name implies: manages the packages: installs, removes, upgrades ... Synaptic is also called "Package Manager" ...

I am very happy that "user installed packages" lists user installed packages. Thanks for that.

m_pav wrote: Tue Jan 16, 2024 3:19 pm Sufficient to say, flatpak -list is a command for that purpose.

It's actually flatpak list

@Germ thanks for that, nice catch. MY propensity to not use flatpaks and my habit of using dashes, ....

@justcomic1 You make a good argument, along with CharlesV about the package manager.

Re: the User Installed Packages, to incorporate a list of installed flatpacks, AFAIK, wouldn't the Flatpack hub package repo list have to be queried and filtered in order to get the list of installed flatpaks?
I simply do not know if there is a local list/database of installed flatpaks because I have no need of them, but I guess there has to be one somewhere.

If the option to check for flatpaks were ever to be included, my preference would be to have a checkbox at the beginning that allows the inclusion of flatpaks and for the results to be distinctly marked and put into a secondary list to avoid confusion when the same named package is available through the regular repos. That is not my decision to make.

m_pav wrote: Sat Jan 20, 2024 5:47 pm @Germ thanks for that, nice catch. MY propensity to not use flatpaks and my habit of using dashes, ....

@justcomic1 You make a good argument, along with CharlesV about the package manager.

Re: the User Installed Packages, to incorporate a list of installed flatpacks, AFAIK, wouldn't the Flatpack hub package repo list have to be queried and filtered in order to get the list of installed flatpaks?
I simply do not know if there is a local list/database of installed flatpaks because I have no need of them, but I guess there has to be one somewhere.

If the option to check for flatpaks were ever to be included, my preference would be to have a checkbox at the beginning that allows the inclusion of flatpaks and for the results to be distinctly marked and put into a secondary list to avoid confusion when the same named package is available through the regular repos. That is not my decision to make.

Hello everyone

What then is the source of ?

Could a button be made to run a script that would make this call?

Just a simple idea from a simple mind.

I do not need the button, but then I am used to managing flatpaks in a terminal (with the exception of permissions, for which I use the flatpak gui application "Flatseal").

Wishing all well...

@m_pav and @everyone:
First of all thank you for taking the time to listen....or at least read..and being open minded.
I agree with the idea of having a check box for Flatpack if it were implemented:
That goes along with my original ambitious request of having various check boxes and tabs and so on.
I think user choice is key.

Thanks to everyone who have suggested various command line options that could potentially be turned into scripts triggered in a GUI.

For those who like the functionality as it is: I definitely would want it to remain easy for you to carry on just using the options you want and ignoring the rest.
The ethos of choice around things like systemd is something I really appreciate about MX - and it would be my desire for any enhancements to work in concert with that.

count-72-on-fingers wrote: Mon Jan 22, 2024 3:51 pm Hello everyone

What then is the source of

Code: Select all

flatpak list --app

?

Could a button be made to run a script that would make this call?

Just a simple idea from a simple mind.

I do not need the button, but then I am used to managing flatpaks in a terminal (with the exception of permissions, for which I use the flatpak gui application "Flatseal").

Wishing all well...

Pretty sure you could make a shortcut that sits on your desktop with the above command and some addition that outputs to a text file.