Hi,
today I updated from core 94 to 95. No problems so far, but I noticed some things that probably could be improved.
ipfire:~# pakfire upgrade CORE UPGR: Upgrading from release 94 to 95 meta-core-upgrade... 100.00% |=============================>| 341.00 B core-upgrade-2.17... 100.00% |=============================>| 38.04 MB PAKFIRE UPGR: core-upgrade-95: Decrypting... PAKFIRE UPGR: core-upgrade-95: Upgrading files and running post-upgrading scripts...
--> Would be nice to have a "--verbose" param to get the output of "/var/log/pakfire/update-core-upgrade-95.log" at this time. Otherwise there is not much output and especially on slow machines the user gets nervous what is happening.
PAKFIRE UPGR: core-upgrade-95: Finished.
Core-Update 2.17 Release: 94 -> 95
Update: linux-pae Version: 0 -> 3.14.57 Release: 0 -> 64
--> Should the previous version/release really be 0?
PAKFIRE RESV: linux-pae: Resolving dependencies...
PAKFIRE UPGR: We are going to install all packages listed above. PAKFIRE INFO: Is this okay? [y/N]
--> Shouldn't the default be Yes?
y linux-pae-3.14.57... 100.00% |=============================>| 25.39 MB PAKFIRE UPGR: linux-pae: Decrypting... PAKFIRE UPGR: linux-pae: Upgrading files and running post-upgrading scripts... PAKFIRE UPGR: linux-pae: Finished.
--> Same as above with "--verbose", here for "/var/log/pakfire/update-linux-pae.log"
From update-linux-pae.log:
*** Installing kernel module dependencies and firmware *** *** Installing kernel module dependencies and firmware done *** *** Resolving executable dependencies *** *** Resolving executable dependencies done*** Could not find 'strip'. Not stripping the initramfs. *** Store current command line parameters *** *** Creating image file *** *** Creating image file done ***
--> Should "strip" exist and is it needed?
Lars
Hi,
I am afraid that I must disappoint you on some of these points. pakfire in IPFire 2 is legacy code and I do not have the time to add new features. It is just maintained as it is and bugs are fixed.
We have a rewrite of this in IPFire 3 already.
On Tue, 2015-12-22 at 19:16 +0100, Lars Schuhmacher wrote:
Hi,
today I updated from core 94 to 95. No problems so far, but I noticed some things that probably could be improved.
ipfire:~# pakfire upgrade CORE UPGR: Upgrading from release 94 to 95 meta-core-upgrade... 100.00% |=============================>| 341.00 B core-upgrade-2.17... 100.00% |=============================>| 38.04 MB PAKFIRE UPGR: core-upgrade-95: Decrypting... PAKFIRE UPGR: core-upgrade-95: Upgrading files and running post- upgrading scripts...
--> Would be nice to have a "--verbose" param to get the output of "/var/log/pakfire/update-core-upgrade-95.log" at this time. Otherwise there is not much output and especially on slow machines the user gets nervous what is happening.
PAKFIRE UPGR: core-upgrade-95: Finished.
Core-Update 2.17 Release: 94 -> 95
Update: linux-pae Version: 0 -> 3.14.57 Release: 0 -> 64
--> Should the previous version/release really be 0?
PAKFIRE RESV: linux-pae: Resolving dependencies...
PAKFIRE UPGR: We are going to install all packages listed above. PAKFIRE INFO: Is this okay? [y/N]
--> Shouldn't the default be Yes?
Why?
y linux-pae-3.14.57... 100.00% |=============================>| 25.39 MB PAKFIRE UPGR: linux-pae: Decrypting... PAKFIRE UPGR: linux-pae: Upgrading files and running post- upgrading scripts... PAKFIRE UPGR: linux-pae: Finished.
--> Same as above with "--verbose", here for "/var/log/pakfire/update-linux-pae.log"
From update-linux-pae.log: *** Installing kernel module dependencies and firmware *** *** Installing kernel module dependencies and firmware done *** *** Resolving executable dependencies *** *** Resolving executable dependencies done*** Could not find 'strip'. Not stripping the initramfs. *** Store current command line parameters *** *** Creating image file *** *** Creating image file done ***
--> Should "strip" exist and is it needed?
All binaries and kernel modules are already stripped, so stripping them again is unnecessary.
Lars
-Michael
On Tue, 22 Dec 2015 23:36:35 +0100, Michael Tremer michael.tremer@ipfire.org wrote:
Hi,
I am afraid that I must disappoint you on some of these points. pakfire in IPFire 2 is legacy code and I do not have the time to add new features. It is just maintained as it is and bugs are fixed.
We have a rewrite of this in IPFire 3 already.
So, there will be more verbose output?
PAKFIRE UPGR: We are going to install all packages listed above. PAKFIRE INFO: Is this okay? [y/N]--> Shouldn't the default be Yes?
Why?
Cause you would normally want to install the new packages? And maybe IPFire relies on the new versions? (I don't know how this is supposed to work)
Lars
On Tue, 2015-12-22 at 23:45 +0100, Larsen wrote:
On Tue, 22 Dec 2015 23:36:35 +0100, Michael Tremer michael.tremer@ipfire.org wrote:
Hi,
I am afraid that I must disappoint you on some of these points. pakfire in IPFire 2 is legacy code and I do not have the time to add new features. It is just maintained as it is and bugs are fixed.
We have a rewrite of this in IPFire 3 already.
So, there will be more verbose output?
Yes some. It will look like this:
http://pakfire.ipfire.org/packages/release/bash/0-4.3-11.ip3/logs/bui ld.x86_64.1.log
AT the beginning of the log there is just a quick overview about the package being built. Then follows a transaction summary of pakfire which lists which packages will be installed/update/removed and after that a progress bar what step of the transaction is currently taking place.
Then there is a build of the bash package which is part of the build system and not pakfire as a package manager.
Basically pakfire installs a temporary chroot environment with all the build dependencies, compiled the package and finally destroys the whole build environment again.
PAKFIRE UPGR: We are going to install all packages listed above. PAKFIRE INFO: Is this okay? [y/N]
--> Shouldn't the default be Yes?
Why?
Cause you would normally want to install the new packages? And maybe IPFire relies on the new versions? (I don't know how this is supposed to work)
You are not asked if you want to install the core update. That will always happen. This is just for the add-on packages. Of course you would want to install them indeed.
I basically thought that "n" is the safe option here and this is usually the default. How do other package managers do this? I would like this to be equal for better user experience. Once you are used to these things... you know?
Lars
-Michael
On Tue, 22 Dec 2015 23:51:13 +0100, Michael Tremer michael.tremer@ipfire.org wrote:
So, there will be more verbose output?
Yes some. It will look like this:
Well, that looks way more verbose =)
PAKFIRE UPGR: We are going to install all packages listedabove. PAKFIRE INFO: Is this okay? [y/N]
--> Shouldn't the default be Yes?
Why?
Cause you would normally want to install the new packages? And maybe IPFire relies on the new versions? (I don't know how this is supposed to work)
You are not asked if you want to install the core update. That will always happen. This is just for the add-on packages. Of course you would want to install them indeed.
I basically thought that "n" is the safe option here and this is usually the default. How do other package managers do this? I would like this to be equal for better user experience. Once you are used to these things... you know?
I can't recall any other software where some situation like this would occur.
In which cases would a user want to _NOT_ install some packages? What is more likely: A newbie that would need this or some advanced user?
Lars
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Other package managers (Debian for one, but there are others I can't think of right now), have Yes set as the default EXCEPT when bringing in packages which require updates to other packages, ie if package A has a dependency on package B in the new version, but not the previous, then you must explicitly tell it to install package A.
However, if package A has a pre-existing dependency on package B, then both A and B are defaulted to being updated.
However, my two cents are for minor things like this, forget it and work on on IPFire 3. We can live with annoyances in 2 if it ends up with more time being spent on 3.
Rod
On 12/22/2015 04:51 PM, Michael Tremer wrote:
On Tue, 2015-12-22 at 23:45 +0100, Larsen wrote:
On Tue, 22 Dec 2015 23:36:35 +0100, Michael Tremer michael.tremer@ipfire.org wrote:
Hi,
I am afraid that I must disappoint you on some of these points. pakfire in IPFire 2 is legacy code and I do not have the time to add new features. It is just maintained as it is and bugs are fixed.
We have a rewrite of this in IPFire 3 already.
So, there will be more verbose output?
Yes some. It will look like this:
http://pakfire.ipfire.org/packages/release/bash/0-4.3-11.ip3/logs/bui
ld.x86_64.1.log
AT the beginning of the log there is just a quick overview about the package being built. Then follows a transaction summary of pakfire which lists which packages will be installed/update/removed and after that a progress bar what step of the transaction is currently taking place.
Then there is a build of the bash package which is part of the build system and not pakfire as a package manager.
Basically pakfire installs a temporary chroot environment with all the build dependencies, compiled the package and finally destroys the whole build environment again.
PAKFIRE UPGR: We are going to install all packages listed above. PAKFIRE INFO: Is this okay? [y/N]
--> Shouldn't the default be Yes?
Why?
Cause you would normally want to install the new packages? And maybe IPFire relies on the new versions? (I don't know how this is supposed to work)
You are not asked if you want to install the core update. That will always happen. This is just for the add-on packages. Of course you would want to install them indeed.
I basically thought that "n" is the safe option here and this is usually the default. How do other package managers do this? I would like this to be equal for better user experience. Once you are used to these things... you know?
Lars
-Michael
- -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net
-
Lars Schuhmacher -
Larsen
-
Michael Tremer -
R. W. Rodolico