Can we improve MintUpdate?
Forum rules
LMDE 2 has reached end of support as of 1-1-2019
LMDE 2 has reached end of support as of 1-1-2019
Re: Can we improve MintUpdate?
Why can't Mint Update give us OPTIONS as to how to proceed with updating?
For example:
You click on Mint Update, the folder opens with the available updates and levels being shown...then asks the user to make a CHOICE ....Terminal or GUI.....to proceed.
Would this be a better way?
For example:
You click on Mint Update, the folder opens with the available updates and levels being shown...then asks the user to make a CHOICE ....Terminal or GUI.....to proceed.
Would this be a better way?
Re: Can we improve MintUpdate?
Out of interest, what would be the difference between using Mint Update with all 5 levels ticked, and using CLI to do a dist-upgrade?
Re: Can we improve MintUpdate?
None.stu1978 wrote:Out of interest, what would be the difference between using Mint Update with all 5 levels ticked, and using CLI to do a dist-upgrade?
Re: Can we improve MintUpdate?
I currently do "sudo apt-get update; sudo apt-get autoclean; sudo apt-get autoremove; sudo apt-get dist-upgrade" once a day.viking777 wrote:None.stu1978 wrote:Out of interest, what would be the difference between using Mint Update with all 5 levels ticked, and using CLI to do a dist-upgrade?
Update wise this would be no more reliable or unreliable than using Mint Update with all 5 levels then?
Re: Can we improve MintUpdate?
That is my opinion yes - I am sure there will be someone who thinks otherwise though.stu1978 wrote:I currently do "sudo apt-get update; sudo apt-get autoclean; sudo apt-get autoremove; sudo apt-get dist-upgrade" once a day.viking777 wrote:None.stu1978 wrote:Out of interest, what would be the difference between using Mint Update with all 5 levels ticked, and using CLI to do a dist-upgrade?
Update wise this would be no more reliable or unreliable than using Mint Update with all 5 levels then?
Edit. I had better qualify that statement. Because I don't use mintupdate, I am not sure if it gives the same level of information about updates that Synaptic does. So in the recent 'vlc' problem I was easily able to see what was going on and refuse the update to libva1, I am not sure if mintmenu gives the same level of information. If it doesn't then I would have to revise my opinion above.
Last edited by viking777 on Sat Mar 05, 2011 11:49 am, edited 1 time in total.
Re: Can we improve MintUpdate?
I have my mintUpdate set a little differently, I only check the 'visible' for levels 4 and 5, that way when I view the available updates,only levels 1-3 are already checked. I have the choice of which or if any I want to check for installation . . .
Re: Can we improve MintUpdate?
Good idea. Perhaps you could answer my question in the Edit of the previous post. Does mintupdate give the same level of information that Synaptic does about what is to be removed, replaced etc?richyrich wrote:I have my mintUpdate set a little differently, I only check the 'visible' for levels 4 and 5, that way when I view the available updates,only levels 1-3 are already checked. I have the choice of which or if any I want to check for installation . . .
Re: Can we improve MintUpdate?
I did find that, and have that set for postgresql v8.4; however it still wants to bring in postgresql v9 if I do a dist-upgrade, probably because v9 is a 'new' install and won't be replacing but alongside v8.4. So something along the lines of 'exclude=' or 'ignore' is nice to have sometimes.zerozero wrote:if i understand what you are saying it looks like "lock version" option in synaptic.CiaW wrote: The only way I have found to set some packages to 'ignore' so they don't update is through MintUpdate. That is a big plus (for me). In my case I don't yet want to upgrade postgresql to v9, and doing a dist-upgrade wants to bring those updates in; so I've been sticking with debdelta and apt-get upgrade until the VLC thing gets sorted out.
Re: Can we improve MintUpdate?
@viking777
Better and more info from Synaptic . . . another thing I forgot to mention about my preferences . . saved me from breakage.
Better and more info from Synaptic . . . another thing I forgot to mention about my preferences . . saved me from breakage.
Re: Can we improve MintUpdate?
I see, and that option is not checked by default then?richyrich wrote:@viking777
Better and more info from Synaptic . . . another thing I forgot to mention about my preferences . . saved me from breakage.
If that is the case it might explain a lot.
Edit. I just took a look at my mintupdate and that option is checked for me also, and I have never used mintupdate on LMDE so I guess that is the default option - it certainly should be.
Re: Can we improve MintUpdate?
The "checked" box is the default on my LMDE 2011 32bit system, but the time delay default is 30 seconds. What and/or Why would a user extend the start up delay by 50%.
Re: Can we improve MintUpdate?
I see. Maybe the start up delay was what richy was referring to. Like yourself malligt, I cannot see what difference that would make to anything, I thought he was referring to the upgrade method.
Re: Can we improve MintUpdate?
Cool, it never used to be checked by default . . thanks Clem.
The delay was my solution for mintUpdate not finding any updates at initial login, when there actually are updates available . . . ever hear that complaint before ?
The delay was my solution for mintUpdate not finding any updates at initial login, when there actually are updates available . . . ever hear that complaint before ?
Re: Can we improve MintUpdate?
Trying to sum up a few post before me, i believe the problem is not in this usage of MintUpdate (5 levels enabled), the problem lays in all those users that don't change the default (and the default is not adapted to LMDE) or even worse those who change it to less (we can fin in the Forum users saying that are going to stick just with level 1 and 2 enabled, seeking a illusory safety)
Re: Can we improve MintUpdate?
So if we have lvl 1-5 it is good to use the mint update ?
I'm using 1-5 from the begining already.
I'm using 1-5 from the begining already.
Re: Can we improve MintUpdate?
CiaW wrote:I did find that, and have that set for postgresql v8.4; however it still wants to bring in postgresql v9 if I do a dist-upgrade, probably because v9 is a 'new' install and won't be replacing but alongside v8.4. So something along the lines of 'exclude=' or 'ignore' is nice to have sometimes.zerozero wrote:if i understand what you are saying it looks like "lock version" option in synaptic.CiaW wrote: The only way I have found to set some packages to 'ignore' so they don't update is through MintUpdate. That is a big plus (for me). In my case I don't yet want to upgrade postgresql to v9, and doing a dist-upgrade wants to bring those updates in; so I've been sticking with debdelta and apt-get upgrade until the VLC thing gets sorted out.
Code: Select all
apt hold postgresql-9.0
Code: Select all
Package: aptdaemon
Pin: release o=Debian
Pin-Priority: 750
Package: *
Pin: release o=Jens Lody
Pin-Priority: 750
Package: hal
Pin: release o=Debian
Pin-Priority: -1
Package: libcairo2
Pin: version 1.8.10-6mfk1
Pin-Priority: 1001
Package: libcairo2-dev
Pin: version 1.8.10-6mfk1
Pin-Priority: 1001
Package: libcairo2-dbg
Pin: version 1.8.10-6mfk1
Pin-Priority: 1001
Package: libcairo2-doc
Pin: version 1.8.10-6mfk1
Pin-Priority: 1001
Package: python-aptdaemon
Pin: release o=Debian
Pin-Priority: 750
Package: python-aptdaemon-gtk
Pin: release o=Debian
Pin-Priority: 750
Code: Select all
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://archive.removed/ubuntu/ lucid-removed/games amd64 Packages
release v=10.04,o=removed,a=lucid-removed,n=lucid-removed,l=removed,c=games
origin archive.removed
500 http://ppa.launchpad.net/mozillateam/thunderbird-stable/ubuntu/ lucid/main amd64 Packages
release v=10.04,o=LP-PPA-mozillateam-thunderbird-stable,a=lucid,n=lucid,l=Thunderbird Stable Channel Packages,c=main
origin ppa.launchpad.net
500 http://ppa.launchpad.net/ubuntu-wine/ppa/ubuntu/ lucid/main amd64 Packages
release v=10.04,o=LP-PPA-ubuntu-wine,a=lucid,n=lucid,l=PPA for Ubuntu Wine Team,c=main
origin ppa.launchpad.net
500 http://ppa.launchpad.net/chromium-daily/stable/ubuntu/ lucid/main amd64 Packages
release v=10.04,o=LP-PPA-chromium-daily-stable,a=lucid,n=lucid,l=PPA for Ubuntu Chromium - Stable Channel,c=main
origin ppa.launchpad.net
500 http://packages.linuxmint.com/ debian/romeo amd64 Packages
release v=1,o=linuxmint,a=debian,n=debian,l=linuxmint,c=romeo
origin packages.linuxmint.com
500 http://packages.linuxmint.com/ debian/import amd64 Packages
release v=1,o=linuxmint,a=debian,n=debian,l=linuxmint,c=import
origin packages.linuxmint.com
500 http://packages.linuxmint.com/ debian/main amd64 Packages
release v=1,o=linuxmint,a=debian,n=debian,l=linuxmint,c=main
origin packages.linuxmint.com
500 http://download.virtualbox.org/virtualbox/debian/ squeeze/contrib amd64 Packages
release o=Oracle Corporation,n=squeeze,l=Oracle Corporation,c=contrib
origin download.virtualbox.org
750 http://apt.jenslody.de/ any/release amd64 Packages
release o=Jens Lody,a=any,n=any,l=Unofficial packages,c=release
origin apt.jenslody.de
500 http://liquorix.net/debian/ sid/main amd64 Packages
release o=liquorix,a=unstable,n=sid,l=cool stuff,c=main
origin liquorix.net
500 http://www.debian-multimedia.org/ testing/non-free amd64 Packages
release v=None,o=Unofficial Multimedia Packages,a=testing,n=wheezy,l=Unofficial Multimedia Packages,c=non-free
origin www.debian-multimedia.org
500 http://www.debian-multimedia.org/ testing/main amd64 Packages
release v=None,o=Unofficial Multimedia Packages,a=testing,n=wheezy,l=Unofficial Multimedia Packages,c=main
origin www.debian-multimedia.org
500 http://security.debian.org/ testing/updates/non-free amd64 Packages
release o=Debian,a=testing,n=wheezy,l=Debian-Security,c=non-free
origin security.debian.org
500 http://security.debian.org/ testing/updates/contrib amd64 Packages
release o=Debian,a=testing,n=wheezy,l=Debian-Security,c=contrib
origin security.debian.org
500 http://security.debian.org/ testing/updates/main amd64 Packages
release o=Debian,a=testing,n=wheezy,l=Debian-Security,c=main
origin security.debian.org
500 http://ftp.ca.debian.org/debian/ testing/non-free amd64 Packages
release o=Debian,a=testing,n=wheezy,l=Debian,c=non-free
origin ftp.ca.debian.org
500 http://ftp.ca.debian.org/debian/ testing/contrib amd64 Packages
release o=Debian,a=testing,n=wheezy,l=Debian,c=contrib
origin ftp.ca.debian.org
500 http://ftp.ca.debian.org/debian/ testing/main amd64 Packages
release o=Debian,a=testing,n=wheezy,l=Debian,c=main
origin ftp.ca.debian.org
Pinned packages:
libcairo2 -> 1.8.10-6mfk1
python-aptdaemon -> 0.31+bzr413-1.1
hal -> 0.5.14-5
aptdaemon -> 0.31+bzr413-1.1
libcairo2-dbg -> 1.8.10-6mfk1
libcairo2-dev -> 1.8.10-6mfk1
python-aptdaemon-gtk -> 0.31+bzr413-1.1
libcairo2-doc -> 1.8.10-6mfk1
https://help.ubuntu.com/community/PinningHowto
http://wiki.debian.org/AptPreferences
If you're interested with the "pinning" approach, this is what man apt_preferences says:
Code: Select all
How APT Interprets Priorities
Priorities (P) assigned in the APT preferences file must be positive or
negative integers. They are interpreted as follows (roughly speaking):
P > 1000
causes a version to be installed even if this constitutes a
downgrade of the package
990 < P <=1000
causes a version to be installed even if it does not come from the
target release, unless the installed version is more recent
500 < P <=990
causes a version to be installed unless there is a version
available belonging to the target release or the installed version
is more recent
100 < P <=500
causes a version to be installed unless there is a version
available belonging to some other distribution or the installed
version is more recent
0 < P <=100
causes a version to be installed only if there is no installed
version of the package
P < 0
prevents the version from being installed
Re: Can we improve MintUpdate?
Earlier on in this (or some other thread on a similar topic, I can't remember) I stated that as I never use mintupdate (always synaptic) I wasn't aware of what information it gives you about what it is intending to do when it upgrades your system. This morning, in order to answer my own question, I updated with mintupdate instead and the difference is immediately clear. As soon as I pressed 'Install updates' it rushed away, downloaded and installed them - no information given, it just did it. Prior to doing this I 'dummied' the update with Synaptic and the behaviour here is very different. As soon as you press 'Apply' it pops up a summary box telling you exactly what it is intending to do, ie what is to be newly installed, what is to be upgraded, and more importantly what is to be removed. This gives you a chance to make a decision as to whether or not you want to proceed with the upgrade before it actually does it. Surely this is the crucial difference between Synaptic and mintupdate, and one answer at least to the question posed in the thread title.
I never understood why people would voluntarily remove a perfectly serviceable media player to upgrade an obscure library file, but apparently people did. Perhaps the reason they did is that they were not given any information as to what they were doing?
I have to say that my test today was not entirely conclusive because in today's updates nothing needed to be removed, but at least by using synaptic I knew that quite clearly before I was committed to the update, using mintupdate I was not given that information.
If you had updated using the command line you would have been given the same information I gleaned from synaptic, but not everyone wants to use the cli. The good news is you don't have to. Synaptic is a gui and it is superior to mintupdate in many respects, but it doesn't launch itself and it requires you to press three buttons in the correct order ('Update', followed by 'mark all upgrades' followed by 'apply'). I don't think that is beyond even the newest of new users to achieve and in return for the extra little bit of effort, it actually informs you of what is going to happen when you press the last of those three buttons. To me that is a small effort for a large return.
I never understood why people would voluntarily remove a perfectly serviceable media player to upgrade an obscure library file, but apparently people did. Perhaps the reason they did is that they were not given any information as to what they were doing?
I have to say that my test today was not entirely conclusive because in today's updates nothing needed to be removed, but at least by using synaptic I knew that quite clearly before I was committed to the update, using mintupdate I was not given that information.
If you had updated using the command line you would have been given the same information I gleaned from synaptic, but not everyone wants to use the cli. The good news is you don't have to. Synaptic is a gui and it is superior to mintupdate in many respects, but it doesn't launch itself and it requires you to press three buttons in the correct order ('Update', followed by 'mark all upgrades' followed by 'apply'). I don't think that is beyond even the newest of new users to achieve and in return for the extra little bit of effort, it actually informs you of what is going to happen when you press the last of those three buttons. To me that is a small effort for a large return.
Re: Can we improve MintUpdate?
Well said. That was the case with vlc as i tested myself. I prefer mostly cli for my updates/upgrades.As soon as I pressed 'Install updates' it rushed away, downloaded and installed them - no information given, it just did it.
So, cli "told me" that libva1 will remove vlc, and that's way i did not upgrade libva1. Then, i check synaptic and in libva1>dependencies, "told" me that libva1 breaks vlc-nox.
I completed this test by using mintupdate: ready to upgrade libva1 said, with the indication that vlc 1.x.z version will replace the vlc 1.x.z version (same version i mean).
Libva1 was labelled as 3 in mintupdate's rating system. Seems safe for someone used in ubuntu based editions, but it is not a very clear and sufficient piece of info for an LMDE user.
There is the problem and i think that a new MintUpdate system must contains that type of information, must explains briefly what the options and the results are, so any user must take his/hers decisions. Otherwise, rating 1-5 etc will be seeming a bit obsolete at least.
Re: Can we improve MintUpdate?
FYI, you can do the same in Bash. Just press Ctrl-R and the letters you want to search for.viking777 wrote:That being the last command I executed with the word Puppy in it. It doesn't even have to be a whole word typing, 'ppy' or any other part of the command you can remember will take you to the last time that combination of letters was used.
Anyhow, I agree that fish is a nice shell!
Re: Can we improve MintUpdate?
You are wrong here - if a bash script is properly written, it has #!/bin/bash on the first line, so bash is used for its execution. No need to switch to bash and then back to fish. ...and if you would switch back to fish, it'd be better idea to type exit, instead of fish.viking777 wrote:....
Another nice thing about it is that if you want to run a command that is written for bash and doesn't work in fish because the syntax is different, you simply switch to the bash shell by typing 'bash' then run your bash command. (and then if you have any sense you switch smartly back to fish again by typing 'fish').
...
Anyway thanks for the tip. fish shell looks great.
Ad update - a good way is to add a shortcut to ~/.bashrc
Code: Select all
alias mupdate='apt update && apt dist-upgrade'