[openFATE 306666] Complete remove-install-update with zypper
Feature added by: James Carter (jimc_uclamath) Feature #306666, revision 1 Title: Complete remove-install-update with zypper openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: James Carter (jimc_uclamath) Description: This is a feature request for zypper-1.0.9-0.1.1 in OpenSuSE 11.1. Obviously the improvements would go into a future SuSE release. In my use case, I have 0.5 FTE to spend on system administration of about 120 researchers' workstations and compute nodes running OpenSuSE. My goals involving zypp in order of frequency of occurrence are: apply security patches; install or remove software according to particular research groups' needs; deploy new machines that have no OS on the disc; and upgrade every 18 months to a new distro version. To accomplish these tasks I need to minimize hand labor in package management. What am I trying to accomplish in package management? Software which is not wanted on a machine should be removed if present, and software which is wanted should be installed if absent, plus dependencies, or upgraded to the latest patch version. I suspect that quite a lot of SuSE users, not just me, would like a package management program which could enforce a locally created pattern, automatically removing, adding and updating packages as needed. Back in SuSE 8.2, rug and zypper/libzypp being in the future, I wrote a perl script to make these goals happen. When zypper first came out I investigated it but found it lacking; the lack of a "dry run" (-D) switch precluded testing. But now with the 64bit x86_64 architecture, and with dependencies involving components and version relations, my script is not flexible enough. I again investigated zypper. With the features now present, specifically the -D (dry run) switch, zypper can now do part of my job if shepherded by a lot of supporting scripting. I would like to list features which would make it useful for the whole job. 1) In rare but important cases we need to blacklist or "hold back" updates. Debian has this feature, and even Microsoft Windows can do it. 2) Zypper should have a "negative removal" mode, that is, rather than listing all the packages you want to remove, you list all the packages you want to keep. Zypper will add all their dependencies, and the non-listed packages (including their exclusive dependencies) will be removed. (My new script uses kludge techniques with rpm, not zypper, to do this calculation, but it's hard and time-consuming, 0.125 second per installed package, to deal with dependencies.) 3) Zypper should have an option to be silent about packages already installed. In other words, you list all the packages you want on the machine, and it installs the missing ones, if any. My new script excludes installed packages from the list of wanted packages before feeding the remainder to zypper, but zypper internally could do this much more neatly. 4) I assume that if I take a back-version machine and trick zypper into orienting on a new distro version, it will recognize that a new version is available for every package and take action accordingly. The distro version (and architecture: changing i586 to x86_64) should be selectable on the command line. 5) The YaST installer downloads a package, then installs it, then repeats. (Or perhaps downloading and installation are smartly overlapped.) Zypper should do the same thing, not requiring disc space for every affected package at the same time. To check that all packages can be downloaded, it can do HEAD requests at the start. There should also be a command line option to not be anally retentive about missing packages: if a transient failure prevents downloading, always retry the package (and those requiring it) later, and if the failure is permanent, install as much as you can, don't die on the spot like zypper presently does. 6) Zypper should install packages in dependency order, so if a failure interrupts the process the machine has no missing dependencies, even if wanted packages are missing. I don't know if zypper already does this. The YaST installer, which I assume is based on libzypp, is seen to install aaa_base kind of in the middle of the set of packages, which leads me to bring up this point. 7) Zypper should have options to remove, install or replace packages itself like it does now, but it should also be able to emit a list or table of affected packages that can be postprocessed before installation or removal. For removal this would be package full names; for installation it would be URLs in the repositories (with an option for plain file names instead of file:/// URLs); for updates both items are needed. It would help in a lot of postprocessing situations if you could optionally ask for the package basenames to be prepended as another field; e.g. if the full name is "zypper-1.0.9-0.1.1" the basename is "zypper". Also helpful in setting up the list of wanted packages would be a separate table of dependency relations, e.g. when the output says "AA BB" it means that package AA is required by package BB. Machine readable format is important; you might make an option to pick tabular output or English texts. In my new script to get dependencies I do "rpm -e --test $pkg" and then parse the English output, which is a crock, takes a lot of time, and is unreliable if you ever "improve" the texts. 8) Wherever a list of thousands of packages or URLs can appear on the command line, zypper should also be able to read these from a file. If either kind of list turns up with zero packages, zypper should shut up and install each of them, same as if one or more packages are on the list. 9) Likely zypper already determines the product, version and architecture from /etc/SuSE-release, but there are so many variants of the first line that it's a crock to parse it. Presently you give "VERSION = 11.1" in the second line (with blanks); I would suggest also giving the PRODUCT and ARCH, and without blanks so in a shell script one can do eval `grep '=' /etc/SuSE-release` rather than dumbly using "tr" to make the blanks go away. 10) Likely it is possible to use the Python binding of libzypp to easily write a wrapper script that easily does all of the above requests. (I prefer Perl; can we have that language binding also?) However, I was not able to find documentation to even get started, i.e. to specify the repositories and a list of packages. So my new script reeks of kludges and fails to use zypper (libzypp) for the most important steps. My final request is for documentation on libzypp that I can use for projects of this kind. Related FATE tickets: * 300758 (../300758) : Show orphan packages (rejected in v11.1). Also 306627 (../306627) , a duplicate with a better use case description. * 302159 (../302159) : Only download packages (rejected in v11.1). Just give me the list of URLs; I'll download them on my home DSL connection, distribute on the home net, and then do rpm -F *.rpm. * 305634 (../305634) : Distro version upgrade from the command line using zypper. Hear, hear! My old script could do this. -- openSUSE Feature: https://features.opensuse.org/306666
Feature changed by: Andreas Jaeger (a_jaeger) Feature #306666, revision 4 Title: Complete remove-install-update with zypper - openSUSE-11.3: Unconfirmed + openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2010-11-15 09:49:47 + reject reason: Not done in time for openSUSE 11.3. Priority Requester: Important + openSUSE-11.4: New + Priority + Requester: Important + Info Provider: (Novell) Requested by: James Carter (jimc_uclamath) Description: This is a feature request for zypper-1.0.9-0.1.1 in OpenSuSE 11.1. Obviously the improvements would go into a future SuSE release. In my use case, I have 0.5 FTE to spend on system administration of about 120 researchers' workstations and compute nodes running OpenSuSE. My goals involving zypp in order of frequency of occurrence are: apply security patches; install or remove software according to particular research groups' needs; deploy new machines that have no OS on the disc; and upgrade every 18 months to a new distro version. To accomplish these tasks I need to minimize hand labor in package management. What am I trying to accomplish in package management? Software which is not wanted on a machine should be removed if present, and software which is wanted should be installed if absent, plus dependencies, or upgraded to the latest patch version. I suspect that quite a lot of SuSE users, not just me, would like a package management program which could enforce a locally created pattern, automatically removing, adding and updating packages as needed. Back in SuSE 8.2, rug and zypper/libzypp being in the future, I wrote a perl script to make these goals happen. When zypper first came out I investigated it but found it lacking; the lack of a "dry run" (-D) switch precluded testing. But now with the 64bit x86_64 architecture, and with dependencies involving components and version relations, my script is not flexible enough. I again investigated zypper. With the features now present, specifically the -D (dry run) switch, zypper can now do part of my job if shepherded by a lot of supporting scripting. I would like to list features which would make it useful for the whole job. 1) In rare but important cases we need to blacklist or "hold back" updates. Debian has this feature, and even Microsoft Windows can do it. 2) Zypper should have a "negative removal" mode, that is, rather than listing all the packages you want to remove, you list all the packages you want to keep. Zypper will add all their dependencies, and the non- listed packages (including their exclusive dependencies) will be removed. (My new script uses kludge techniques with rpm, not zypper, to do this calculation, but it's hard and time-consuming, 0.125 second per installed package, to deal with dependencies.) 3) Zypper should have an option to be silent about packages already installed. In other words, you list all the packages you want on the machine, and it installs the missing ones, if any. My new script excludes installed packages from the list of wanted packages before feeding the remainder to zypper, but zypper internally could do this much more neatly. 4) I assume that if I take a back-version machine and trick zypper into orienting on a new distro version, it will recognize that a new version is available for every package and take action accordingly. The distro version (and architecture: changing i586 to x86_64) should be selectable on the command line. 5) The YaST installer downloads a package, then installs it, then repeats. (Or perhaps downloading and installation are smartly overlapped.) Zypper should do the same thing, not requiring disc space for every affected package at the same time. To check that all packages can be downloaded, it can do HEAD requests at the start. There should also be a command line option to not be anally retentive about missing packages: if a transient failure prevents downloading, always retry the package (and those requiring it) later, and if the failure is permanent, install as much as you can, don't die on the spot like zypper presently does. 6) Zypper should install packages in dependency order, so if a failure interrupts the process the machine has no missing dependencies, even if wanted packages are missing. I don't know if zypper already does this. The YaST installer, which I assume is based on libzypp, is seen to install aaa_base kind of in the middle of the set of packages, which leads me to bring up this point. 7) Zypper should have options to remove, install or replace packages itself like it does now, but it should also be able to emit a list or table of affected packages that can be postprocessed before installation or removal. For removal this would be package full names; for installation it would be URLs in the repositories (with an option for plain file names instead of file:/// URLs); for updates both items are needed. It would help in a lot of postprocessing situations if you could optionally ask for the package basenames to be prepended as another field; e.g. if the full name is "zypper-1.0.9-0.1.1" the basename is "zypper". Also helpful in setting up the list of wanted packages would be a separate table of dependency relations, e.g. when the output says "AA BB" it means that package AA is required by package BB. Machine readable format is important; you might make an option to pick tabular output or English texts. In my new script to get dependencies I do "rpm -e --test $pkg" and then parse the English output, which is a crock, takes a lot of time, and is unreliable if you ever "improve" the texts. 8) Wherever a list of thousands of packages or URLs can appear on the command line, zypper should also be able to read these from a file. If either kind of list turns up with zero packages, zypper should shut up and install each of them, same as if one or more packages are on the list. 9) Likely zypper already determines the product, version and architecture from /etc/SuSE-release, but there are so many variants of the first line that it's a crock to parse it. Presently you give "VERSION = 11.1" in the second line (with blanks); I would suggest also giving the PRODUCT and ARCH, and without blanks so in a shell script one can do eval `grep '=' /etc/SuSE-release` rather than dumbly using "tr" to make the blanks go away. 10) Likely it is possible to use the Python binding of libzypp to easily write a wrapper script that easily does all of the above requests. (I prefer Perl; can we have that language binding also?) However, I was not able to find documentation to even get started, i.e. to specify the repositories and a list of packages. So my new script reeks of kludges and fails to use zypper (libzypp) for the most important steps. My final request is for documentation on libzypp that I can use for projects of this kind. Related FATE tickets: * 300758 (../300758) : Show orphan packages (rejected in v11.1). Also 306627 (../306627) , a duplicate with a better use case description. * 302159 (../302159) : Only download packages (rejected in v11.1). Just give me the list of URLs; I'll download them on my home DSL connection, distribute on the home net, and then do rpm -F *.rpm. * 305634 (../305634) : Distro version upgrade from the command line using zypper. Hear, hear! My old script could do this. + Discussion: + #1: Andreas Jaeger (a_jaeger) (2010-11-15 09:50:33) + Jano, could you comment on this, please? -- openSUSE Feature: https://features.opensuse.org/306666
participants (1)
-
fate_noreply＠suse.de