The upgrade from 3.5.13.2 to R14 includes a lot of package "renames".
After a clean i386 Wheezy 3.5.13.2 install of kde-trinity is upgraded to R14 RC2, an "apt-get autoremove" removes 48 transitional dummy packages. This is good.
However there are still (roughly) 15 transitional dummy packages whose descriptions say they can be safely uninstalled. All that is preventing them from being uninstalled is two meta packages - kde-trinity and kde-core-trinity. And so the conscientious sysadmin removes the two unnecessary meta packages and the (roughly) 15 remaining transitional dummy packages.
And the next "apt-get autoremove" eats 290 packages which is most of Trinity.
If you had less than a normal kde-trinity installation of 3.5.13.2 this problem hits you much sooner and without uninstalling any meta packages.
What to do? Something in the release notes?
--Mike
On 2014/12/11 12:48 PM, Mike Bird wrote:
The upgrade from 3.5.13.2 to R14 includes a lot of package "renames".
After a clean i386 Wheezy 3.5.13.2 install of kde-trinity is upgraded to R14 RC2, an "apt-get autoremove" removes 48 transitional dummy packages. This is good.
However there are still (roughly) 15 transitional dummy packages whose descriptions say they can be safely uninstalled. All that is preventing them from being uninstalled is two meta packages - kde-trinity and kde-core-trinity. And so the conscientious sysadmin removes the two unnecessary meta packages and the (roughly) 15 remaining transitional dummy packages.
And the next "apt-get autoremove" eats 290 packages which is most of Trinity.
If you had less than a normal kde-trinity installation of 3.5.13.2 this problem hits you much sooner and without uninstalling any meta packages.
What to do? Something in the release notes?
--Mike
In the installation instructions for Debian/Ubuntu, it is recommended to use aptitude instead of apt-get to upgrade. It seems that using apt-get does not resolve all dependencies correctly (see bug 2245 on bugszilla).
Do you have a change to retry using aptitude?
Cheers Michele
On Wed December 10 2014 20:03:33 Michele Calgaro wrote:
In the installation instructions for Debian/Ubuntu, it is recommended to use aptitude instead of apt-get to upgrade. It seems that using apt-get does not resolve all dependencies correctly (see bug 2245 on bugszilla).
Do you have a change to retry using aptitude?
I would not recommend either apt-get or aptitude over the other as one is worse in some cases and the other is worse in other cases.
Aptitude is maybe a bit smarter than apt-get and tends to autoremove automatically which is a separate step with apt-get.
With a without-recommends standard install of 3.5.13.2 upgrade to R14 R2 aptitude avoids the conflict mentioned in bug 2245 because aptitude autoremoves kdebase-kio-plugins-trinity during the dist-upgrade, along with autoremoving roughly 47 other packages that would be a separate step with apt-get.
When you try to purge the remaining roughly 15 dummy packages with aptitude it is smart enough to figure out on its own that kde-trinity and kde-core-trinity need to be removed ... but then you're in the same position as with apt-get - most of Trinity is autoremoved.
//
The above considered only a standard install. Let's now compare apt-get versus aptitude in the case of a small 3.5.13.2 install of just "kdm-trinity kdevelop-trinity" along with their depends but not their recommends.
With apt-get after the dist-upgrade some but not all of the dummy packages are amenable to autoremove. Purging the remaining dummy packages results in the entire Trinity install becoming autoremovable.
With aptitude the dist-upgrade proceeds as with apt-get except most of the dummy packages are autoremoved during the dist-upgrade. The only two remaining dummy packages are kdm-trinity and kdevelop-trinity. When aptitude is told to purge these two the entire Trinity install is autoremoved.
//
My guess is that the transition packages should somehow transfer their manual/auto state to the new packages but I don't know a clean way of doing this.
--Mike
On 2014/12/11 05:37 PM, Mike Bird wrote:
On Wed December 10 2014 20:03:33 Michele Calgaro wrote:
In the installation instructions for Debian/Ubuntu, it is recommended to use aptitude instead of apt-get to upgrade. It seems that using apt-get does not resolve all dependencies correctly (see bug 2245 on bugszilla).
Do you have a change to retry using aptitude?
I would not recommend either apt-get or aptitude over the other as one is worse in some cases and the other is worse in other cases.
Aptitude is maybe a bit smarter than apt-get and tends to autoremove automatically which is a separate step with apt-get.
With a without-recommends standard install of 3.5.13.2 upgrade to R14 R2 aptitude avoids the conflict mentioned in bug 2245 because aptitude autoremoves kdebase-kio-plugins-trinity during the dist-upgrade, along with autoremoving roughly 47 other packages that would be a separate step with apt-get.
When you try to purge the remaining roughly 15 dummy packages with aptitude it is smart enough to figure out on its own that kde-trinity and kde-core-trinity need to be removed ... but then you're in the same position as with apt-get - most of Trinity is autoremoved.
//
The above considered only a standard install. Let's now compare apt-get versus aptitude in the case of a small 3.5.13.2 install of just "kdm-trinity kdevelop-trinity" along with their depends but not their recommends.
With apt-get after the dist-upgrade some but not all of the dummy packages are amenable to autoremove. Purging the remaining dummy packages results in the entire Trinity install becoming autoremovable.
With aptitude the dist-upgrade proceeds as with apt-get except most of the dummy packages are autoremoved during the dist-upgrade. The only two remaining dummy packages are kdm-trinity and kdevelop-trinity. When aptitude is told to purge these two the entire Trinity install is autoremoved.
//
My guess is that the transition packages should somehow transfer their manual/auto state to the new packages but I don't know a clean way of doing this.
--Mike
Hi Mike, I haven't (yet) tried an upgrade from 3.5.13.2 to r14.0.0 myself (I will have to test on a VM sometime next week), but when you are going for the dummy package removal, I suggest you try this: run aptitude in interactive mode, select the dummy packages to remove, press 'g'. You will have a screen with a summary of what packages are going to be removed, which most likely will include most of TDE packages (based on your mail) as "autodependency (A)". Mark tdebase, tdelibs and all other "general" tde packages as "keep". This should possibly keep most of TDE installed, while allowing you to remove those dummy packages.
Having said that, I am going to try a similar upgrade as well, sometime next week. If I find better ways, I will let you know.
Cheers Michele
On Thu December 11 2014 01:47:03 Michele Calgaro wrote:
I haven't (yet) tried an upgrade from 3.5.13.2 to r14.0.0 myself (I will have to test on a VM sometime next week), but when you are going for the dummy package removal, I suggest you try this: run aptitude in interactive mode, select the dummy packages to remove, press 'g'. You will have a screen with a summary of what packages are going to be removed, which most likely will include most of TDE packages (based on your mail) as "autodependency (A)". Mark tdebase, tdelibs and all other "general" tde packages as "keep". This should possibly keep most of TDE installed, while allowing you to remove those dummy packages.
Hi Michele,
I've been trying to figure out a simple way to protect inexperienced users.
The safest approach I've found thus far is:
apt-get update apt-get install tde-trinity apt-get dist-upgrade
This is for Debian. Ubuntu may need a different second step just as initial installs are different for Ubuntu.
I also tried this with aptitude but aptitude goes crazy.
--Mike
On 12/11/2014 06:58 PM, Mike Bird wrote:
I've been trying to figure out a simple way to protect inexperienced users.
The safest approach I've found thus far is:
apt-get update apt-get install tde-trinity apt-get dist-upgrade
This is for Debian. Ubuntu may need a different second step just as initial installs are different for Ubuntu.
I also tried this with aptitude but aptitude goes crazy.
--Mike
Thanks Mike, I agree with you that we need to find an easy and reproducible way to update, then we can add an "update from v3.5.13.2" to the wiki on the website. Interesting is the fact that you and Slavek found different "good way", i.e. Slavek had problem with apt-get while you have problem with aptitude. I am going to try both ways myself as well, then let's see what's the best we can come up with. Thanks for the feedback so far.
Cheers Michele
On Friday 12 of December 2014 02:02:27 Michele Calgaro wrote:
On 12/11/2014 06:58 PM, Mike Bird wrote:
I've been trying to figure out a simple way to protect inexperienced users.
The safest approach I've found thus far is:
apt-get update apt-get install tde-trinity apt-get dist-upgrade
This is for Debian. Ubuntu may need a different second step just as initial installs are different for Ubuntu.
I also tried this with aptitude but aptitude goes crazy.
--Mike
Thanks Mike, I agree with you that we need to find an easy and reproducible way to update, then we can add an "update from v3.5.13.2" to the wiki on the website. Interesting is the fact that you and Slavek found different "good way", i.e. Slavek had problem with apt-get while you have problem with aptitude. I am going to try both ways myself as well, then let's see what's the best we can come up with. Thanks for the feedback so far.
Cheers Michele
If I understand correctly, Mike did not have a problem with aptitude during the upgrade, but only after upgrade when he tried to remove the original kde-trinity / kde-core-trinity / kde-devel-trinity without also installed their successors tde-trinity / tde-core-trinity / tde-devel-trinity.
While in my tests were fundamental problems during the upgrade with apt-get.
On Thu December 11 2014 17:29:10 Slávek Banko wrote:
If I understand correctly, Mike did not have a problem with aptitude during the upgrade, but only after upgrade when he tried to remove the original kde-trinity / kde-core-trinity / kde-devel-trinity without also installed their successors tde-trinity / tde-core-trinity / tde-devel-trinity.
While in my tests were fundamental problems during the upgrade with apt-get.
That's correct. I don't know yet if the missing Conflicts which caused a problem for apt-get is fixed in R14 Final.
There is something newer on the master server and now mirroring to Copernicus that I could test but I don't yet know if it has finished building.
--Mike
On Friday 12 of December 2014 03:08:02 Mike Bird wrote:
On Thu December 11 2014 17:29:10 Slávek Banko wrote:
If I understand correctly, Mike did not have a problem with aptitude during the upgrade, but only after upgrade when he tried to remove the original kde-trinity / kde-core-trinity / kde-devel-trinity without also installed their successors tde-trinity / tde-core-trinity / tde-devel-trinity.
While in my tests were fundamental problems during the upgrade with apt-get.
That's correct. I don't know yet if the missing Conflicts which caused a problem for apt-get is fixed in R14 Final.
There is something newer on the master server and now mirroring to Copernicus that I could test but I don't yet know if it has finished building.
--Mike
For information, Conflicts is not missing - is present from November 25 - commit 69b99797 (tde-packaging). But despite this Conflicts I observed problems when using apt-get.
On Thu December 11 2014 18:21:51 Slávek Banko wrote:
For information, Conflicts is not missing - is present from November 25 - commit 69b99797 (tde-packaging). But despite this Conflicts I observed problems when using apt-get.
In roughly a dozen R14 RC2 test "apt-get dist-upgrade" from 3.5.13.2 I did not encounter the problem you had already fixed in 69b99797.
What I did encounter was the problem reported in bug 2245 for which Michele suggested a fix in comment 2.
--Mike
On Friday 12 of December 2014 03:42:47 Mike Bird wrote:
On Thu December 11 2014 18:21:51 Slávek Banko wrote:
For information, Conflicts is not missing - is present from November 25 - commit 69b99797 (tde-packaging). But despite this Conflicts I observed problems when using apt-get.
In roughly a dozen R14 RC2 test "apt-get dist-upgrade" from 3.5.13.2 I did not encounter the problem you had already fixed in 69b99797.
What I did encounter was the problem reported in bug 2245 for which Michele suggested a fix in comment 2.
--Mike
Moment, I do not understand here. In one sentence you say that you're not encounter the problem solved by commit 69b99797, but then you say that you encounter a problem described in bug 2245. But bug 2245 is just the problem what "should" solve Conflict, which was set in commit 69b99797 :)
I reported that with apt-get upgrade just does not work correctly. So if I understand correctly, you now confirm the same thing - that with apt-get upgrade does not work properly. As I have right now tested, for solving problem also for apt-get would probably suffice modify version to one from the following:
<= 4:3.5.13.2+ << 4:3.5.13.3~ << 4:14.0.0~ (as suggested by Michele)
Tim, now it is probably too late for rebuild and publishing?
On Thu December 11 2014 19:51:46 Slávek Banko wrote:
Moment, I do not understand here. In one sentence you say that you're not encounter the problem solved by commit 69b99797, but then you say that you encounter a problem described in bug 2245. But bug 2245 is just the problem what "should" solve Conflict, which was set in commit 69b99797 :)
Maybe I misunderstand 69b99797 but it looks like a fix for the packaging of libtdepim1a-trinity and libtdepim1-trinity-dev for just three distros - Lenny, Squeeze, and Maverick - whereas bug 2245 concerns the packaging of tdelibs-data-trinity and my testing has been exclusively with Wheezy and it looks like you originally filed bug 2245 based on a problem with Wheezy.
--Mike
On Friday 12 of December 2014 05:24:20 Mike Bird wrote:
On Thu December 11 2014 19:51:46 Slávek Banko wrote:
Moment, I do not understand here. In one sentence you say that you're not encounter the problem solved by commit 69b99797, but then you say that you encounter a problem described in bug 2245. But bug 2245 is just the problem what "should" solve Conflict, which was set in commit 69b99797 :)
Maybe I misunderstand 69b99797 but it looks like a fix for the packaging of libtdepim1a-trinity and libtdepim1-trinity-dev for just three distros - Lenny, Squeeze, and Maverick - whereas bug 2245 concerns the packaging of tdelibs-data-trinity and my testing has been exclusively with Wheezy and it looks like you originally filed bug 2245 based on a problem with Wheezy.
--Mike
Yeah, good point - should be mentioned commit eec4bd7f - November 17. Perhaps I should go to sleep :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Thu December 11 2014 19:51:46 Slávek Banko wrote:
Moment, I do not understand here. In one sentence you say that you're not encounter the problem solved by commit 69b99797, but then you say that you encounter a problem described in bug 2245. But bug 2245 is just the problem what "should" solve Conflict, which was set in commit 69b99797 :)
Maybe I misunderstand 69b99797 but it looks like a fix for the packaging of libtdepim1a-trinity and libtdepim1-trinity-dev for just three distros - Lenny, Squeeze, and Maverick - whereas bug 2245 concerns the packaging of tdelibs-data-trinity and my testing has been exclusively with Wheezy and it looks like you originally filed bug 2245 based on a problem with Wheezy.
--Mike
The structure of our Debian/Ubuntu packaging tree is that all Ubuntu distributions are symlinked to the "maverick" folder, while all Debian distributions are symlinked to the "squeeze" folder. This is due to the fact that, at least for now, one set of packaging files works on all supported versions. In the future this may change, hence the reason for keeping the distribution names instead of one large "debian" or "ubuntu" folder.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014/12/11 06:58 PM, Mike Bird wrote:
On Thu December 11 2014 01:47:03 Michele Calgaro wrote:
I haven't (yet) tried an upgrade from 3.5.13.2 to r14.0.0 myself (I will have to test on a VM sometime next week), but when you are going for the dummy package removal, I suggest you try this: run aptitude in interactive mode, select the dummy packages to remove, press 'g'. You will have a screen with a summary of what packages are going to be removed, which most likely will include most of TDE packages (based on your mail) as "autodependency (A)". Mark tdebase, tdelibs and all other "general" tde packages as "keep". This should possibly keep most of TDE installed, while allowing you to remove those dummy packages.
Hi Michele,
I've been trying to figure out a simple way to protect inexperienced users.
The safest approach I've found thus far is:
apt-get update apt-get install tde-trinity apt-get dist-upgrade
This is for Debian. Ubuntu may need a different second step just as initial installs are different for Ubuntu.
I also tried this with aptitude but aptitude goes crazy.
--Mike
Mike, Slavek, Tim, I am doing testing on upgrading from 3.5.13.2 to R14.0.0 on a default Wheezy installation. Using the "installation" instructions on the wiki page fails, so we will probably need to update those pages and differentiate between "new install" and "upgrade". Given the slowness of package transfer (I am using the official packages, not my own build, to avoid any possible mistake), I am still testing various ways. I will update again later on.
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014/12/11 06:58 PM, Mike Bird wrote:
On Thu December 11 2014 01:47:03 Michele Calgaro wrote:
I haven't (yet) tried an upgrade from 3.5.13.2 to r14.0.0 myself (I will have to test on a VM sometime next week), but when you are going for the dummy package removal, I suggest you try this: run aptitude in interactive mode, select the dummy packages to remove, press 'g'. You will have a screen with a summary of what packages are going to be removed, which most likely will include most of TDE packages (based on your mail) as "autodependency (A)". Mark tdebase, tdelibs and all other "general" tde packages as "keep". This should possibly keep most of TDE installed, while allowing you to remove those dummy packages.
Hi Michele,
I've been trying to figure out a simple way to protect inexperienced users.
The safest approach I've found thus far is:
apt-get update apt-get install tde-trinity apt-get dist-upgrade
This is for Debian. Ubuntu may need a different second step just as initial installs are different for Ubuntu.
I also tried this with aptitude but aptitude goes crazy.
--Mike
If seems the download from the server/mirrors is more reliable now. I gave up testing for a few days, but now it seems that the download is (although slowly) progressing without timeout, 509 bandwidth limitiation or error of sort. It is stalls occasionaly, but a stop-go will resume it. Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2014/12/11 06:58 PM, Mike Bird wrote:
On Thu December 11 2014 01:47:03 Michele Calgaro wrote:
I haven't (yet) tried an upgrade from 3.5.13.2 to r14.0.0 myself (I will have to test on a VM sometime next week), but when you are going for the dummy package removal, I suggest you try this: run aptitude in interactive mode, select the dummy packages to remove, press 'g'. You will have a screen with a summary of what packages are going to be removed, which most likely will include most of TDE packages (based on your mail) as "autodependency (A)". Mark tdebase, tdelibs and all other "general" tde packages as "keep". This should possibly keep most of TDE installed, while allowing you to remove those dummy packages.
Hi Michele,
I've been trying to figure out a simple way to protect inexperienced users.
The safest approach I've found thus far is:
apt-get update apt-get install tde-trinity apt-get dist-upgrade
This is for Debian. Ubuntu may need a different second step just as initial installs are different for Ubuntu.
I also tried this with aptitude but aptitude goes crazy.
--Mike
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks.
- apt-get update
- apt-get install tde-trinity.
This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of packages to install, the process containing "apt-get install tde-trinity" is not an just upgrade, but will install many other packages. Moreover, as you mention, this step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
1) apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test machines ran smoothly - without any hitch - and it's "really just upgrade".
On Mon December 22 2014 02:26:11 Slávek Banko wrote:
As I've mentioned many times before, this procedure on all my test machines ran smoothly - without any hitch - and it's "really just upgrade".
Agreed that would be good, but what in your configuration prevents autoremove from removing needed packages?
Did you originally perform a standard TDE install or did you perform some kind of expert install that told aptitude more about which packages you want to keep?
--Mike
On Monday 22 of December 2014 18:33:06 Mike Bird wrote:
On Mon December 22 2014 02:26:11 Slávek Banko wrote:
As I've mentioned many times before, this procedure on all my test machines ran smoothly - without any hitch - and it's "really just upgrade".
Agreed that would be good, but what in your configuration prevents autoremove from removing needed packages?
Did you originally perform a standard TDE install or did you perform some kind of expert install that told aptitude more about which packages you want to keep?
--Mike
On my usual machines I have installed only such packages that I need - without use of metapackages. On the test machine with Ubuntu I used TDE LiveCD - tde-3.5.13.2-ubuntu-12.04.2 - here is used metapackage trinity-livecd.
On my test machine with Debian Squeeze is therefore the difference between 'apt-get install tde-trinity' and 'aptitude dist-upgrade' abysmal:
apt-get install tde-trinity:
72 upgraded, 456 newly installed, 1 to remove and 31 not upgraded. Need to get 339 MB of archives. After this operation, 687 MB of additional disk space will be used.
aptitude dist-upgrade:
92 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 137 MB of archives. After unpacking 63.8 MB will be used.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/22/2014 07:26 PM, Slávek Banko wrote:
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
Ok, will test later and report back. Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
1) apt-get update 2) aptitude dist-upgrade 3) aptitude install tde-trinity -> then choose to resolve the conflict by removing kde-trinity and kde-core-trinity
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
Hi Michele,
I think the answer is that for people who had in the past done a standard Trinity install they should include the "apt-get install tde-trinity" step to avoid autoremove problems but that for experts such as Slávek who have customized their installations and understand the consequences then they can skip that step.
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/24/2014 06:02 AM, Mike Bird wrote:
Hi Michele,
I think the answer is that for people who had in the past done a standard Trinity install they should include the "apt-get install tde-trinity" step to avoid autoremove problems but that for experts such as Slávek who have customized their installations and understand the consequences then they can skip that step.
--Mike
Thanks Mike, makes a lot of sense. After all we are looking at providing a procedure for "standard" users :-) I will just wait for Slavek's test result first, since I understand that it can tests repeatedly on the same computer. Cheers Michele
On Wednesday 24 of December 2014 07:48:26 Michele Calgaro wrote:
On 12/24/2014 06:02 AM, Mike Bird wrote:
Hi Michele,
I think the answer is that for people who had in the past done a standard Trinity install they should include the "apt-get install tde-trinity" step to avoid autoremove problems but that for experts such as Slávek who have customized their installations and understand the consequences then they can skip that step.
--Mike
Thanks Mike, makes a lot of sense. After all we are looking at providing a procedure for "standard" users :-) I will just wait for Slavek's test result first, since I understand that it can tests repeatedly on the same computer. Cheers Michele
Yes, that's right - thanks to the use aufs I can run test on the same computer again and again and again :)
On Tuesday 23 of December 2014 09:11:53 Michele Calgaro wrote:
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
- apt-get update
No problems.
- aptitude dist-upgrade
96 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 147 MB of archives. After unpacking 63.7 MB will be used.
No problems.
- aptitude install tde-trinity -> then choose to resolve the conflict
by removing kde-trinity and kde-core-trinity
0 packages upgraded, 406 newly installed, 0 to remove and 0 not upgraded. Need to get 231 MB of archives. After unpacking 626 MB will be used.
Oops, that's a bit much.
I think we could recommend something like this:
If you had installed metapackage kde-trinity, kde-core-trinity or kde-devel-trinity, these are not updated automatically. For the update is necessary to use one of the following:
aptitude install tde-trinity aptitude install tde-core-trinity aptitude install tde-devel-trinity
As I watched, there are several transitional dummy packages which would still have had to be removed manually. For example kde-i18n-*, kio-locate, kradio,... For such I would suggest the following:
4) Run aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check and delete unneeded packages.
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/26/2014 04:26 AM, Slávek Banko wrote:
On Tuesday 23 of December 2014 09:11:53 Michele Calgaro wrote:
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
- apt-get update
No problems.
- aptitude dist-upgrade
96 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 147 MB of archives. After unpacking 63.7 MB will be used.
No problems.
Note: only 64 new packages installed.
- aptitude install tde-trinity -> then choose to resolve the conflict by removing kde-trinity and
kde-core-trinity
0 packages upgraded, 406 newly installed, 0 to remove and 0 not upgraded. Need to get 231 MB of archives. After unpacking 626 MB will be used.
Oops, that's a bit much.
Well, "too much" is subjective. Basically the "general" user is trying to upgrade from a previous kde-install, so this step is just installing whatever package was not upgraded from step 2. On my wheezy installation steps 2 install about 250 packages and step 3 about 200 if my memory is right. The total is about 450, which is similar to the number you reported on a previous email (http://trinity-devel.pearsoncomputing.net/?0::14312)
I think we could recommend something like this:
If you had installed metapackage kde-trinity, kde-core-trinity or kde-devel-trinity, these are not updated automatically. For the update is necessary to use one of the following:
aptitude install tde-trinity aptitude install tde-core-trinity aptitude install tde-devel-trinity
As I watched, there are several transitional dummy packages which would still have had to be removed manually. For example kde-i18n-*, kio-locate, kradio,... For such I would suggest the following:
- Run aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check and delete unneeded
packages.
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
What about we propose two possibilities?
1) same as the one I proposed. This one would basically upgrade/install all TDE R14.0.0 and get rid of dummy packages. This solution would be intended for "generic" users who want a simple way to upgrade all TDE
2) same solution that you suggested, i.e. step 1 and step 2, then run aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check/delete unneeded packages and install equivalent tde packages. This would be intended for more expert users, who can choose what to install and what not.
What do you think? Cheers Michele
On Friday 26 of December 2014 14:25:52 Michele Calgaro wrote:
On 12/26/2014 04:26 AM, Slávek Banko wrote:
On Tuesday 23 of December 2014 09:11:53 Michele Calgaro wrote:
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
- apt-get update
No problems.
- aptitude dist-upgrade
96 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 147 MB of archives. After unpacking 63.7 MB will be used.
No problems.
Note: only 64 new packages installed.
Yes, 64 is perfectly fine, because on this test machine is not installed "everything", but substantial and potentially conflicting packages.
- aptitude install tde-trinity -> then choose to resolve the conflict
by removing kde-trinity and kde-core-trinity
0 packages upgraded, 406 newly installed, 0 to remove and 0 not upgraded. Need to get 231 MB of archives. After unpacking 626 MB will be used.
Oops, that's a bit much.
Well, "too much" is subjective. Basically the "general" user is trying to upgrade from a previous kde-install, so this step is just installing whatever package was not upgraded from step 2. On my wheezy installation steps 2 install about 250 packages and step 3 about 200 if my memory is right. The total is about 450, which is similar to the number you reported on a previous email (http://trinity-devel.pearsoncomputing.net/?0::14312)
Essential however is that in step 2 are updated 'all installed' packages. Regardless of how was installed the previous version of TDE - whether the packages were selected individually (as is in my case) or meta-package was used (as are ordinary users). The only packages that are not updated in the previous step are kde-trinity, kde-core-trinity and kde-devel-trinity ... and possibly their new dependencies => new packages.
Therefore 406 new packages from my example is simply much, because it causes installation a lot of packages that "I did not want to have" => I did not installed intentionally. Therefore my proposal from previous mail to the reformulation of step 3 to optional => "If you have installed metapackage kde..." - see paragraph below.
I think we could recommend something like this:
If you had installed metapackage kde-trinity, kde-core-trinity or kde-devel-trinity, these are not updated automatically. For the update is necessary to use one of the following:
aptitude install tde-trinity aptitude install tde-core-trinity aptitude install tde-devel-trinity
As I watched, there are several transitional dummy packages which would still have had to be removed manually. For example kde-i18n-*, kio-locate, kradio,... For such I would suggest the following:
- Run aptitude in interactive mode, enter Limit Display
'~i-trinity~ddummy" and manually check and delete unneeded packages.
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
What about we propose two possibilities?
- same as the one I proposed. This one would basically upgrade/install all
TDE R14.0.0 and get rid of dummy packages. This solution would be intended for "generic" users who want a simple way to upgrade all TDE
- same solution that you suggested, i.e. step 1 and step 2, then run
aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check/delete unneeded packages and install equivalent tde packages. This would be intended for more expert users, who can choose what to install and what not.
What do you think? Cheers Michele
I think that the proposed procedures are not mutually exclusive, but complementary => no problem to combine it into a single process:
Steps 1) and 2) are identical. Step 3) is optional => for users that have previously installed meta-packages kde-trinity / kde-core-trinity / kde-devel-trinity. Step 4) is optional => for advanced users who wants to do more housekeeping.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/26/2014 11:36 PM, Slávek Banko wrote:
On Friday 26 of December 2014 14:25:52 Michele Calgaro wrote:
On 12/26/2014 04:26 AM, Slávek Banko wrote:
On Tuesday 23 of December 2014 09:11:53 Michele Calgaro wrote:
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
- apt-get update
No problems.
- aptitude dist-upgrade
96 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 147 MB of archives. After unpacking 63.7 MB will be used.
No problems.
Note: only 64 new packages installed.
Yes, 64 is perfectly fine, because on this test machine is not installed "everything", but substantial and potentially conflicting packages.
- aptitude install tde-trinity -> then choose to resolve the conflict by removing kde-trinity and
kde-core-trinity
0 packages upgraded, 406 newly installed, 0 to remove and 0 not upgraded. Need to get 231 MB of archives. After unpacking 626 MB will be used.
Oops, that's a bit much.
Well, "too much" is subjective. Basically the "general" user is trying to upgrade from a previous kde-install, so this step is just installing whatever package was not upgraded from step 2. On my wheezy installation steps 2 install about 250 packages and step 3 about 200 if my memory is right. The total is about 450, which is similar to the number you reported on a previous email (http://trinity-devel.pearsoncomputing.net/?0::14312)
Essential however is that in step 2 are updated 'all installed' packages. Regardless of how was installed the previous version of TDE - whether the packages were selected individually (as is in my case) or meta-package was used (as are ordinary users). The only packages that are not updated in the previous step are kde-trinity, kde-core-trinity and kde-devel-trinity ... and possibly their new dependencies => new packages.
Therefore 406 new packages from my example is simply much, because it causes installation a lot of packages that "I did not want to have" => I did not installed intentionally. Therefore my proposal from previous mail to the reformulation of step 3 to optional => "If you have installed metapackage kde..." - see paragraph below.
I think we could recommend something like this:
If you had installed metapackage kde-trinity, kde-core-trinity or kde-devel-trinity, these are not updated automatically. For the update is necessary to use one of the following:
aptitude install tde-trinity aptitude install tde-core-trinity aptitude install tde-devel-trinity
As I watched, there are several transitional dummy packages which would still have had to be removed manually. For example kde-i18n-*, kio-locate, kradio,... For such I would suggest the following:
- Run aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check and delete
unneeded packages.
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
What about we propose two possibilities?
- same as the one I proposed. This one would basically upgrade/install all TDE R14.0.0 and get rid of dummy
packages. This solution would be intended for "generic" users who want a simple way to upgrade all TDE
- same solution that you suggested, i.e. step 1 and step 2, then run aptitude in interactive mode, enter Limit
Display '~i-trinity~ddummy" and manually check/delete unneeded packages and install equivalent tde packages. This would be intended for more expert users, who can choose what to install and what not.
What do you think? Cheers Michele
I think that the proposed procedures are not mutually exclusive, but complementary => no problem to combine it into a single process:
Steps 1) and 2) are identical. Step 3) is optional => for users that have previously installed meta-packages kde-trinity / kde-core-trinity / kde-devel-trinity. Step 4) is optional => for advanced users who wants to do more housekeeping.
Ok, let's settle on this version then. I will update the installation pages early next week. Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/26/2014 11:36 PM, Slávek Banko wrote:
On Friday 26 of December 2014 14:25:52 Michele Calgaro wrote:
On 12/26/2014 04:26 AM, Slávek Banko wrote:
On Tuesday 23 of December 2014 09:11:53 Michele Calgaro wrote:
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote:
Looks like the mirror is now fully working, since it takes less than 30 minutes to do a fully upgrade. So I have tested sevaral ways to upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence suggested by Mike seems to be the most reliable/reproducable, but with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. This fails at some point. 3) apt-get -f install. This succeeded, but trying to login after this stage gives the error "Could not start kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have a fully working TDE R14.0.0 system. Running aptitude in CLI mode and pressing 'g', comes up with a list of packages that can be deleted. This at times is most of the TDE installation. To fix this do the following. 5) run 'aptitude', search tde-trinity (which should be shown as *un*installed, mark as 'to install' and 'g'. This will make R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' again, comes up with a list of packages that can be deleted. Proceed.
I have noticed over several upgrade runs, that the list of packages that can be deleted is not always the same, not sure why although some of the upgrade run were interrupted/resumed several times due to the slow download bandwidth of previous days. It seems that dummy packages have to be manually removed. dpkg -l | grep -i dummy gives a list of such packages.
I will modify the installation instructions adding an "Update from 3.5.13.2" section to it. If you have any specific comments that you would like to add to the above, please let me know (once again :-) )
Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
- apt-get update
No problems.
- aptitude dist-upgrade
96 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 147 MB of archives. After unpacking 63.7 MB will be used.
No problems.
Note: only 64 new packages installed.
Yes, 64 is perfectly fine, because on this test machine is not installed "everything", but substantial and potentially conflicting packages.
- aptitude install tde-trinity -> then choose to resolve the conflict by removing kde-trinity and
kde-core-trinity
0 packages upgraded, 406 newly installed, 0 to remove and 0 not upgraded. Need to get 231 MB of archives. After unpacking 626 MB will be used.
Oops, that's a bit much.
Well, "too much" is subjective. Basically the "general" user is trying to upgrade from a previous kde-install, so this step is just installing whatever package was not upgraded from step 2. On my wheezy installation steps 2 install about 250 packages and step 3 about 200 if my memory is right. The total is about 450, which is similar to the number you reported on a previous email (http://trinity-devel.pearsoncomputing.net/?0::14312)
Essential however is that in step 2 are updated 'all installed' packages. Regardless of how was installed the previous version of TDE - whether the packages were selected individually (as is in my case) or meta-package was used (as are ordinary users). The only packages that are not updated in the previous step are kde-trinity, kde-core-trinity and kde-devel-trinity ... and possibly their new dependencies => new packages.
Therefore 406 new packages from my example is simply much, because it causes installation a lot of packages that "I did not want to have" => I did not installed intentionally. Therefore my proposal from previous mail to the reformulation of step 3 to optional => "If you have installed metapackage kde..." - see paragraph below.
I think we could recommend something like this:
If you had installed metapackage kde-trinity, kde-core-trinity or kde-devel-trinity, these are not updated automatically. For the update is necessary to use one of the following:
aptitude install tde-trinity aptitude install tde-core-trinity aptitude install tde-devel-trinity
As I watched, there are several transitional dummy packages which would still have had to be removed manually. For example kde-i18n-*, kio-locate, kradio,... For such I would suggest the following:
- Run aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check and delete
unneeded packages.
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
What about we propose two possibilities?
- same as the one I proposed. This one would basically upgrade/install all TDE R14.0.0 and get rid of dummy
packages. This solution would be intended for "generic" users who want a simple way to upgrade all TDE
- same solution that you suggested, i.e. step 1 and step 2, then run aptitude in interactive mode, enter Limit
Display '~i-trinity~ddummy" and manually check/delete unneeded packages and install equivalent tde packages. This would be intended for more expert users, who can choose what to install and what not.
What do you think? Cheers Michele
I think that the proposed procedures are not mutually exclusive, but complementary => no problem to combine it into a single process:
Steps 1) and 2) are identical. Step 3) is optional => for users that have previously installed meta-packages kde-trinity / kde-core-trinity / kde-devel-trinity. Step 4) is optional => for advanced users who wants to do more housekeeping.
Slavek, I have updated both Debian and Ubuntu installation pages on the wiki. If you compare the "Upgrade" section on both pages, you will see that "Debian's point A" is not present in the Ubuntu version. This is because the package names to install TDE in Ubuntu are different from Debian. I do not have an Ubuntu system to test on. Could you check and let me know if there is any error or missing info regarding the Ubuntu page? Thanks.
Cheers Michele
On Monday 29 of December 2014 04:01:55 Michele Calgaro wrote:
On 12/26/2014 11:36 PM, Slávek Banko wrote:
On Friday 26 of December 2014 14:25:52 Michele Calgaro wrote:
On 12/26/2014 04:26 AM, Slávek Banko wrote:
On Tuesday 23 of December 2014 09:11:53 Michele Calgaro wrote:
On 2014/12/22 07:26 PM, Slávek Banko wrote:
On Monday 22 of December 2014 11:06:20 Michele Calgaro wrote: > Looks like the mirror is now fully working, since it takes less than > 30 minutes to do a fully upgrade. So I have tested sevaral ways to > upgrade from a standard 3.5.13.2 install to 14.0.0. The sequence > suggested by Mike seems to be the most reliable/reproducable, but > with some tweeks. 1) apt-get update 2) apt-get install tde-trinity. > This fails at some point. 3) apt-get -f install. This succeeded, but > trying to login after this stage gives the error "Could not start > kstartupconfig...." 4) apt-get dist-upgrade After this stage, I have > a fully working TDE R14.0.0 system. Running aptitude in CLI mode and > pressing 'g', comes up with a list of packages that can be deleted. > This at times is most of the TDE installation. To fix this do the > following. 5) run 'aptitude', search tde-trinity (which should be > shown as *un*installed, mark as 'to install' and 'g'. This will make > R14.0.0 stick in your system 6) running 'aptitude' and pressing 'g' > again, comes up with a list of packages that can be deleted. > Proceed. > > I have noticed over several upgrade runs, that the list of packages > that can be deleted is not always the same, not sure why although > some of the upgrade run were interrupted/resumed several times due > to the slow download bandwidth of previous days. It seems that dummy > packages have to be manually removed. dpkg -l | grep -i dummy gives > a list of such packages. > > I will modify the installation instructions adding an "Update from > 3.5.13.2" section to it. If you have any specific comments that you > would like to add to the above, please let me know (once again :-) ) > > Cheers Michele
I must again point out - if the user perform a manual selection of
packages to
install, the process containing "apt-get install tde-trinity" is not
an just
upgrade, but will install many other packages. Moreover, as you
mention, this
step fails. That does not sound like a good way to upgrade.
Please, test this simple procedure:
- apt-get update 2) aptitude dist-upgrade
As I've mentioned many times before, this procedure on all my test
machines
ran smoothly - without any hitch - and it's "really just upgrade".
Slavek, I tested your way and the upgrade goes smooth. Nevertheless after the process is completed a lot of dummy packages are still installed. Using the following procedure gets rid of those dummy packages and leaves a clean upgrade.
- apt-get update
No problems.
- aptitude dist-upgrade
96 packages upgraded, 64 newly installed, 15 to remove and 0 not upgraded. Need to get 147 MB of archives. After unpacking 63.7 MB will be used.
No problems.
Note: only 64 new packages installed.
Yes, 64 is perfectly fine, because on this test machine is not installed "everything", but substantial and potentially conflicting packages.
- aptitude install tde-trinity -> then choose to resolve the
conflict by removing kde-trinity and kde-core-trinity
0 packages upgraded, 406 newly installed, 0 to remove and 0 not upgraded. Need to get 231 MB of archives. After unpacking 626 MB will be used.
Oops, that's a bit much.
Well, "too much" is subjective. Basically the "general" user is trying to upgrade from a previous kde-install, so this step is just installing whatever package was not upgraded from step 2. On my wheezy installation steps 2 install about 250 packages and step 3 about 200 if my memory is right. The total is about 450, which is similar to the number you reported on a previous email (http://trinity-devel.pearsoncomputing.net/?0::14312)
Essential however is that in step 2 are updated 'all installed' packages. Regardless of how was installed the previous version of TDE - whether the packages were selected individually (as is in my case) or meta-package was used (as are ordinary users). The only packages that are not updated in the previous step are kde-trinity, kde-core-trinity and kde-devel-trinity ... and possibly their new dependencies => new packages.
Therefore 406 new packages from my example is simply much, because it causes installation a lot of packages that "I did not want to have" => I did not installed intentionally. Therefore my proposal from previous mail to the reformulation of step 3 to optional => "If you have installed metapackage kde..." - see paragraph below.
I think we could recommend something like this:
If you had installed metapackage kde-trinity, kde-core-trinity or kde-devel-trinity, these are not updated automatically. For the update is necessary to use one of the following:
aptitude install tde-trinity aptitude install tde-core-trinity aptitude install tde-devel-trinity
As I watched, there are several transitional dummy packages which would still have had to be removed manually. For example kde-i18n-*, kio-locate, kradio,... For such I would suggest the following:
- Run aptitude in interactive mode, enter Limit Display
'~i-trinity~ddummy" and manually check and delete unneeded packages.
Can you test on your machines as well and let me know? If confirmed, I will update the installation instructions. Cheers Michele
What about we propose two possibilities?
- same as the one I proposed. This one would basically upgrade/install
all TDE R14.0.0 and get rid of dummy packages. This solution would be intended for "generic" users who want a simple way to upgrade all TDE
- same solution that you suggested, i.e. step 1 and step 2, then run
aptitude in interactive mode, enter Limit Display '~i-trinity~ddummy" and manually check/delete unneeded packages and install equivalent tde packages. This would be intended for more expert users, who can choose what to install and what not.
What do you think? Cheers Michele
I think that the proposed procedures are not mutually exclusive, but complementary => no problem to combine it into a single process:
Steps 1) and 2) are identical. Step 3) is optional => for users that have previously installed meta-packages kde-trinity / kde-core-trinity / kde-devel-trinity. Step 4) is optional => for advanced users who wants to do more housekeeping.
Slavek, I have updated both Debian and Ubuntu installation pages on the wiki. If you compare the "Upgrade" section on both pages, you will see that "Debian's point A" is not present in the Ubuntu version. This is because the package names to install TDE in Ubuntu are different from Debian. I do not have an Ubuntu system to test on. Could you check and let me know if there is any error or missing info regarding the Ubuntu page? Thanks.
Cheers Michele
I think it looks good, thank you.
By the way, on Ubuntu is not any package that should not be automatically updated by step 2. Package trinity-rename-meta should take care of all meta-packages. The only exceptions should be really just kde-trinity, kde-core-trinity and kde-devel-trinity on Debian.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/01/2015 11:37 PM, Slávek Banko wrote:
Slavek,
I have updated both Debian and Ubuntu installation pages on the wiki. If you compare the "Upgrade" section on both pages, you will see that "Debian's point A" is not present in the Ubuntu version. This is because the package names to install TDE in Ubuntu are different from Debian. I do not have an Ubuntu system to test on. Could you check and let me know if there is any error or missing info regarding the Ubuntu page? Thanks.
Cheers Michele
I think it looks good, thank you.
By the way, on Ubuntu is not any package that should not be automatically updated by step 2. Package trinity-rename-meta should take care of all meta-packages. The only exceptions should be really just kde-trinity, kde-core-trinity and kde-devel-trinity on Debian.
-- Slávek
Hi Slavek, thanks for checking :-)
Michele
On Thursday 11 of December 2014 04:48:43 Mike Bird wrote:
The upgrade from 3.5.13.2 to R14 includes a lot of package "renames".
After a clean i386 Wheezy 3.5.13.2 install of kde-trinity is upgraded to R14 RC2, an "apt-get autoremove" removes 48 transitional dummy packages. This is good.
However there are still (roughly) 15 transitional dummy packages whose descriptions say they can be safely uninstalled. All that is preventing them from being uninstalled is two meta packages - kde-trinity and kde-core-trinity. And so the conscientious sysadmin removes the two unnecessary meta packages and the (roughly) 15 remaining transitional dummy packages.
And the next "apt-get autoremove" eats 290 packages which is most of Trinity.
If you had less than a normal kde-trinity installation of 3.5.13.2 this problem hits you much sooner and without uninstalling any meta packages.
What to do? Something in the release notes?
Yes, there is a problem in that packages kde-trinity, kde-core-trinity and kde-devel-trinity are not automatically replaced with new tde-trinity, tde-core-trinity and tde-devel-trinity. The reason is that the previous KDE meta-packages have different version numbers, and they were so far in advance compared to the standard R14 numbering.
As you suggest, this would be good to mention in the instructions for upgrading on Debian.
Incidentally, there are also general comments about the replacement packages during upgrade - for example, replace kpowersave to tdepowersave and knetworkmanager to tdenetworkmanager. This is independent of the distribution. Where should we put these instructions?
On 2014/12/11 01:14 PM, Slávek Banko wrote:
Incidentally, there are also general comments about the replacement packages during upgrade - for example, replace kpowersave to tdepowersave and knetworkmanager to tdenetworkmanager. This is independent of the distribution. Where should we put these instructions?
Probably the best place is in the Release Notes. If you can write a small paragraph with the required text, I can later added to the wiki page.
Cheers Michele
PS: Ubuntu instructions have been corrected.
-
Michele Calgaro -
Mike Bird -
Slávek Banko -
Timothy Pearson