[opensuse] zypper [up vs patch && dup {from 11.3 to 11.4 ??}
Hello. I'm a multi-Linux distro Multi-boot user. I have a strong preference
for text based package managements systems that can be run when X isn't.
Currently I have a better understanding of apt-get, pacman and equo from my
Ubuntu, Arch, and Sabayon installations than I have of zypper.
I've looked at man zypper on my OpenSuSE 11.3 installation. But as much as
I like Linux, and have been using it for years, I still get easily confused
by much of the documentation. So please bear with me if I only partially
understand what I'm talking about...
First question: "zypper up vs zypper patch":
I gather that zypper up (without arguments) will update all installed
packages to the latest available versions except when the vendor changed or
some manual dependency issues are involved.
Whereas zypper patch (without args) will install all needed patches (which
will sometimes even remove existing software and WILL change the package
vendor if needed. (I suspect that it will even downgrade a package if
necessary. And that it won't touch any packages outside the scope of the
patch involved...)
So in general I reason that to keep a system properly up to date, both are
sometimes needed.
But if one is going to do both, is it better to:
"zypper patch" before or after "zypper up"???
My other question is possibly more specific. I can't say I really
understand the repos. In general I wouldn't make changes to my repo list
unless I started to get errors... (I'm afraid I'll mess them up)
But looking at the man information for "zypper dup" I gather that it's
possible to upgrade an existing openSuSE 11.3 to 11.4 (or higher if
applicable) with "zypper dup" (I do hope so. As I really hate having to
recreate my user environment (such as keyboard shortcuts that are
drastically different from the defaults etc... And having to manually add all
my preferred applications like I would if I simply burned the latest iso and
reinstalled)
And I think I understand that it's best to first make sure the correct repos
for the new version are installed and selected...
But I'm almost clueless when it comes down to how to go about doing that...
There's a copy of the current output of "zypper lr" at:
http://pastebin.com/DVJcGgBJ
Could somebody walk me through the process of setting my repos up for the
dist-upgrade??? Or at least point me at a how-to that doesn't expect me to
be a computer science graduate...
TIA
--
| ~^~ ~^~
| <?> <?> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <
On Thu, Sep 15, 2011 at 11:31:19AM -0400, J(tWdy)P wrote:
Hello. I'm a multi-Linux distro Multi-boot user. I have a strong preference for text based package managements systems that can be run when X isn't. Currently I have a better understanding of apt-get, pacman and equo from my Ubuntu, Arch, and Sabayon installations than I have of zypper.
I've looked at man zypper on my OpenSuSE 11.3 installation. But as much as I like Linux, and have been using it for years, I still get easily confused by much of the documentation. So please bear with me if I only partially understand what I'm talking about...
First question: "zypper up vs zypper patch":
I gather that zypper up (without arguments) will update all installed packages to the latest available versions except when the vendor changed or some manual dependency issues are involved.
Whereas zypper patch (without args) will install all needed patches (which will sometimes even remove existing software and WILL change the package vendor if needed. (I suspect that it will even downgrade a package if necessary. And that it won't touch any packages outside the scope of the patch involved...)
No, that would be "zypper dup". zypper patch uses the updateinfo/patch meta information to update the packages according to the patches we have in our update repository. It will not do vendor changes, downgrades or deinstalls. Only zypper "dup" aka "distribution upgrade" does. So in order of aggressiveness: - zypper patch only official updates - zypper up updates with all available package updates, no vendor change or downgrade. (includes "patch" parts too) - zypper dup try to move the system to the state reflected by the repositories. useful for switching to a new distro, or following openSUSE Factory. Ciao, MArcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Sep 15, 2011 at 11:41 AM, Marcus Meissner
On Thu, Sep 15, 2011 at 11:31:19AM -0400, J(tWdy)P wrote:
Hello. I'm a multi-Linux distro Multi-boot user. I have a strong preference for text based package managements systems that can be run when X isn't. Currently I have a better understanding of apt-get, pacman and equo from my Ubuntu, Arch, and Sabayon installations than I have of zypper.
I've looked at man zypper on my OpenSuSE 11.3 installation. But as much as I like Linux, and have been using it for years, I still get easily confused by much of the documentation. So please bear with me if I only partially understand what I'm talking about...
First question: "zypper up vs zypper patch":
I gather that zypper up (without arguments) will update all installed packages to the latest available versions except when the vendor changed or some manual dependency issues are involved.
Whereas zypper patch (without args) will install all needed patches (which will sometimes even remove existing software and WILL change the package vendor if needed. (I suspect that it will even downgrade a package if necessary. And that it won't touch any packages outside the scope of the patch involved...)
No, that would be "zypper dup".
zypper patch uses the updateinfo/patch meta information to update the packages according to the patches we have in our update repository.
It will not do vendor changes, downgrades or deinstalls.
Only zypper "dup" aka "distribution upgrade" does.
So in order of aggressiveness:
- zypper patch only official updates - zypper up updates with all available package updates, no vendor change or downgrade. (includes "patch" parts too)
- zypper dup try to move the system to the state reflected by the repositories. useful for switching to a new distro, or following openSUSE Factory.
Ciao, MArcus
And here's the instructions for doing a version upgrade: http://en.opensuse.org/SDB:System_upgrade Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It would appear that on Sep 15, Dave Howorth did say:
As well as using the zypper command-line tool are you aware that you can also use YaST without having X running? There is an ncurses version called 'yast' whilst the X GUI version is 'yast2'.
Yeah but when I use yast {even with the X gui version} it REALLY confuses me. NONE of it's interface is intuitive to me. If I was going to use a gui, I'd want something a LOT more like synaptic... But really though I'm more comfortable with CLI as long as there is some sanity checking (like with zypper when it tells me what it's about to do and gives me a chance to say "NO" Or with Sabayon's equo does as long as I remember to use the --ask switch... Its so much easier to use copy/paste from my notes to the command line with CLI. But thanks for the info. It would appear that on Sep 15, Marcus Meissner did say:
On Thu, Sep 15, 2011 at 11:31:19AM -0400, J(tWdy)P wrote:
- - - - - - - - -< s n i p >- - - - - - - - - -
Whereas zypper patch (without args) will install all needed patches (which will sometimes even remove existing software and WILL change the package vendor if needed. (I suspect that it will even downgrade a package if necessary. And that it won't touch any packages outside the scope of the patch involved...)
No, that would be "zypper dup".
zypper patch uses the updateinfo/patch meta information to update the packages according to the patches we have in our update repository.
It will not do vendor changes, downgrades or deinstalls.
Only zypper "dup" aka "distribution upgrade" does.
So in order of aggressiveness:
- zypper patch only official updates - zypper up updates with all available package updates, no vendor change or downgrade. (includes "patch" parts too)
- zypper dup try to move the system to the state reflected by the repositories. useful for switching to a new distro, or following openSUSE Factory.
Thanks. So I'm thinking I'll just use zypper up most of the time with an occasional zypper dup when there are getting to be too many packages listed as NOT being updated... It would appear that on Sep 15, Greg Freemyer did say:
And here's the instructions for doing a version upgrade:
Thanks... That looks like a great how-to.
One concern, it seems to advise to only use a limited few repos for the
zypper dup step, and that having too many could lead to a failed upgrade.
But what happens to software installed with 11.3 versions of repos for
which I haven't installed the 11,4 versions of???
Things like my enlightenment desktop come to mind...
It wouldn't uninstall it on me if I didn't include the 11.4 version of
download.opensuse.org/repositories/X11:/Enlightenment/openSUSE_11.4/
And if I didn't include:
download.opensuse.org/repositories/games/openSUSE_11.4/
would it be likely to uninstall a lot of games???
--
| ~^~ ~^~
| <?> <?> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2011-09-16 at 12:56 -0400, Joe(theWordy)Philbrook wrote:
Yeah but when I use yast {even with the X gui version} it REALLY confuses me. NONE of it's interface is intuitive to me. If I was going to use a gui,
I find YaST much more intuitive than zypper. You can review rpm by rpm wether they will be upgraded or not, for example.
So in order of aggressiveness:
- zypper patch only official updates - zypper up updates with all available package updates, no vendor change or downgrade. (includes "patch" parts too)
- zypper dup try to move the system to the state reflected by the repositories. useful for switching to a new distro, or following openSUSE Factory.
Thanks. So I'm thinking I'll just use zypper up most of the time with an occasional zypper dup when there are getting to be too many packages listed as NOT being updated...
I would stay clear of zypper dup, unless you really understand what it does, or if you use it to change distro version.
Thanks... That looks like a great how-to.
One concern, it seems to advise to only use a limited few repos for the zypper dup step, and that having too many could lead to a failed upgrade.
Correct. It is quite complicated to guess what it will do.
But what happens to software installed with 11.3 versions of repos for which I haven't installed the 11,4 versions of???
If there is another version in the enabled repos, it will be downgraded or upgraded to it. If there is no version, it will stay put. I think. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk518/YACgkQtTMYHG2NR9UX9wCeKbRWv5ateaDB9ZyN/qerw98I aa0AoJMbg7fF3rAN70adXHk3H4lQRLvL =3zs7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It would appear that on Sep 18, Carlos E. R. did say:
On Friday, 2011-09-16 at 12:56 -0400, Joe(theWordy)Philbrook wrote:
Yeah but when I use yast {even with the X gui version} it REALLY confuses me. NONE of it's interface is intuitive to me. If I was going to use a gui,
I find YaST much more intuitive than zypper. You can review rpm by rpm wether they will be upgraded or not, for example.
Perhaps the way you think is more in tune to how yast works than the way I think is... Did I mention that I multi boot several Linux. ALL of which need to be kept updated. And each of them have slightly different issues. checking rpm by rpm is a relatively low priority for me. All of them have a cli based tool that works for me. (most of the time anyway) And all of these cli tools will print a list of the changes it's about to make and ask for confirmation. Though with Sabayon's equo I have to use the --ask option. But equo makes up for it with the most detailed and readable screen output of all of them including zypper. It's not hard to scroll the terminal window back to see the whole list... Heck even when I'm doing an update from a root shell on tty1 (Not having even started the gui) I can use <Shift>+<Up> to scroll the buffer back. AND I like not being dependent on X remaining stable while updating things it depends on...
So in order of aggressiveness:
- zypper patch only official updates - zypper up updates with all available package updates, no vendor change or downgrade. (includes "patch" parts too)
- zypper dup try to move the system to the state reflected by the repositories. useful for switching to a new distro, or following openSUSE Factory.
Thanks. So I'm thinking I'll just use zypper up most of the time with an occasional zypper dup when there are getting to be too many packages listed as NOT being updated...
I would stay clear of zypper dup, unless you really understand what it does, or if you use it to change distro version.
Yeah, I used to feel that way, but gradually the list of files that it bothered to say wouldn't be upgraded, by "zypper up" became too large for comfort. I don't know what percentage was for "vendor changes" but zypper dup got my 11.3 as up to date as possible. Which might have helped when I used it to upgrade to 11.4...
Thanks... That looks like a great how-to.
One concern, it seems to advise to only use a limited few repos for the zypper dup step, and that having too many could lead to a failed upgrade.
Correct.
It is quite complicated to guess what it will do.
Well what I did was look at the pending changes, and when I didn't like some of them I tweaked a few things. For example I use two browsers. Firefox (which works better with my on-line banking. And opera which once configured my way is more intuitive for me. But for those times when I actually want java enabled iced-tea doesn't work well with it. I'd replaced the iced-tea plugin with sun's plugin but either zypper up or zypper dup wanted to put iced-tea back in unless I "lock"ed the sun plugin. But I wasn't comfortable locking the 11.3 version while upgrading to 11.4. This was an issue until I added sun's regular runtime environment. THEN zypper finally stopped trying to all iced-tea... Figuring that out might have been a bit complicated. But it was more like "'Trial' and 'abort before error'" than guesswork.
But what happens to software installed with 11.3 versions of repos for which I haven't installed the 11,4 versions of???
If there is another version in the enabled repos, it will be downgraded or upgraded to it. If there is no version, it will stay put. I think.
Yeah That's what seemed to happen. Except that I think a dependency issue
with one of the new packages will bump the old "not in repo" packages.
I tried without my specialty repos first but I didn't like the number of
packages it said would be uninstalled. So I tuned them back on. I found I
needed to disable the "devel" repos. (I'd aborted on the first error)
Then I ran it. but after about a half hour it complained about not being
able to download something from games. I was too far in to feel like I
could safely abort, so I ignored several instances of a failed download
from games. several of which must have been a reoccurring dependency for the
same 3 packages. When it was done I disabled games and ran "zypper verify"
and with the games repo out of the way it found another more viable source
for the three packages...
Now the only problem I was having was a gpg2 issue that was already an
issue in 11.3. (I've since solved that issue... But that's another thread.)
I knew it was a gamble leaving the 11.4 versions of so many repo's enabled.
But it saved me a lot of reconfiguring. And besides if it really hosed my
system, all that would mean for me would be to use one of the other 4 linux
while I downloaded and burned an iso. Course then I'd have had to do it all
the hard way where I needed to install mc, and completely recreated the
entire (desktop) keyboard shortcut configuration for each and every DE I
install (usually E17, E16 & Xfce ( I mostly gave up on kde {except for a
few apps like konsole...} when they started cramming ver 4 down my throat.)
Fortunately for me, the gamble paid off.
But any way thanks for the advice. I'm sure that for you yast is the right
choice. That's one of the best things about Linux. There are so many
right ways to do things.
--
| --- ___
| <0> <-> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| ~\___/~ <
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-09-19 at 04:03 -0400, Joe(theWordy)Philbrook wrote:
I would stay clear of zypper dup, unless you really understand what it does, or if you use it to change distro version.
Yeah, I used to feel that way, but gradually the list of files that it bothered to say wouldn't be upgraded, by "zypper up" became too large for comfort. I don't know what percentage was for "vendor changes" but zypper dup got my 11.3 as up to date as possible. Which might have helped when I used it to upgrade to 11.4...
That's the wrong way of thinking. If zypper up will not upgrade something it is because the rules you have set impede it, so what it says will do is the correct thing. What you have to do is change the rules. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk53Ys0ACgkQtTMYHG2NR9XiZwCcDKjk2H+iFwMxElZJiMM1RbZX Tl0An1D+Dmeprj7SpSnbPan6XeZZYlO8 =8zMg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It would appear that on Sep 19, Carlos E. R. did say:
On Monday, 2011-09-19 at 04:03 -0400, Joe(theWordy)Philbrook wrote:
I would stay clear of zypper dup, unless you really understand what it does, or if you use it to change distro version.
Yeah, I used to feel that way, but gradually the list of files that it bothered to say wouldn't be upgraded, by "zypper up" became too large for comfort. I don't know what percentage was for "vendor changes" but zypper dup got my 11.3 as up to date as possible. Which might have helped when I used it to upgrade to 11.4...
That's the wrong way of thinking.
No what would be the wrong way of thinking for *_ME_* would be to think like anybody besides myself...
If zypper up will not upgrade something it is because the rules you have set impede it, so what it says will do is the correct thing.
Agreed if the in-place "rules" for it's behavior impede it's upgrading a package then it is doing the correct thing. It's serving to alert me that there may be an issue that needs resolving for a more complete upgrade.
What you have to do is change the rules.
Or change the method. Especially if I don't know which rule that I myself
didn't craft is impeding the results I'm looking for...
I did mention I'm keeping multiple distros up to date... Even if I was smart
enough to customize the default "rules" for each distro's package
management, I wouldn't likely have the time... In any case "I" never set
any "rules" for zypper (except for an occasional "lock" which I never leave in
place long enough to forget it's there.)
{Of course, if it was possible to set a negative lock to tell zypper to NEVER
install a particular package, I'd have simply set a permanent lock to "rule"
out iced-tea some time ago...}
* quoted excerpts from "man zypper"
=> update (up) [options] [packagename] ...
=> Update installed packages with newer versions, where possible.
=>
=> This command will not update packages which would require change
=> of package vendor unless the vendor is specified in
=> /etc/zypp/vendors.d, or which would require manual resolution of
=> problems with dependencies. Such non-installable updates will
=> then be listed in separate section of the summary as "The fol-
=> lowing package updates will NOT be installed:".
I don't have it in me to track all the vendor changes to keep a viable
venders.d file updated. Nor to second guess the dependencies issues that
would require "manual intervention". If I see one or two particularly desired
upgrade(s) listed under "will NOT be installed" I might abort and try a
direct install command to see what {up/down}grades, and removes, would be
triggered by the ones I care about. But would otherwise tend to ignore the
list until it became too large for my comfort. At which point the quick fix
is to {provisionally} use a bigger hammer:
=> dist-upgrade (dup) [options]
=> Perform a distribution upgrade. This command applies the state
=> of (specified) repositories onto the system; upgrades (or even
=> downgrades) installed packages to versions found in reposito-
=> ries, removes packages that are no longer in the repositories
=> and pose a dependency problem for the upgrade, handles package
=> splits and renames, etc.
Paying close attention to what (if anything) would be "removed" to bring my
system more fully in sync with the current repo defaults. If I don't like
the changes it would make then I might go back to "zypper up" until I can
find the time to figure out some "manual intervention"...
Any way that's the way my brain resolves such issues...
But thanks for the advice. && Have a 'nice' day.
--
| --- ___
| <0> <-> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| ~\___/~ <
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2011-09-19 at 23:42 -0400, Joe(theWordy)Philbrook wrote:
In any case "I" never set any "rules" for zypper (except for an occasional "lock" which I never leave in place long enough to forget it's there.)
Yes, you do :-) There are two main "rules": the priority level you give each repo, and if the possible update is in a different repo implying a vendor change (meaning, that once you choose a package from a certain repo, it will not change to a newer version on another repo). - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk54j3gACgkQtTMYHG2NR9UbLQCdEUiBZEOvtNiR6l88IwL5pTvA ot4AnRM9KLPkuitJY7zZQYGEJQ6cxnXc =fbeI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It would appear that on Sep 20, Carlos E. R. did say:
On Monday, 2011-09-19 at 23:42 -0400, Joe(theWordy)Philbrook wrote:
In any case "I" never set any "rules" for zypper (except for an occasional "lock" which I never leave in place long enough to forget it's there.)
Yes, you do :-)
There are two main "rules": the priority level you give each repo, and if the possible update is in a different repo implying a vendor change (meaning, that once you choose a package from a certain repo, it will not change to a newer version on another repo).
Well if the priority level of each repo is set by default relative to the
order in which they are added, and so was randomly set to the order in
which I first discovered the existence of each repo, then I'll concede that
I inadvertently may have set that rule... ;-)
In which case, how would I go about assigning a different priority level?
But as far as the existence of some rule that would cause "zypper up" to
change vendor in spite of how man zypper implies that it won't, that rule
would have been set by some default value, as the only way I could be said
to have set it would be by the omission of any action to set it explicitly...
How does one set a rule to allow zypper up to change vendor?
And would that allow it to change vendor on download error such as a bad
checksum on the current vendor's copy of a package that is also available in
another enabled repo?
--
| ~^~ ~^~
| <?> <?> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <
* Joe(theWordy)Philbrook
It would appear that on Sep 20, Carlos E. R. did say:
On Monday, 2011-09-19 at 23:42 -0400, Joe(theWordy)Philbrook wrote:
In any case "I" never set any "rules" for zypper (except for an occasional "lock" which I never leave in place long enough to forget it's there.)
Yes, you do :-)
There are two main "rules": the priority level you give each repo, and if the possible update is in a different repo implying a vendor change (meaning, that once you choose a package from a certain repo, it will not change to a newer version on another repo).
Well if the priority level of each repo is set by default relative to the order in which they are added, and so was randomly set to the order in which I first discovered the existence of each repo, then I'll concede that I inadvertently may have set that rule... ;-)
In which case, how would I go about assigning a different priority level?
zypper --help zypper mr --help zypper mr -p <some number> <repo>
But as far as the existence of some rule that would cause "zypper up" to change vendor in spite of how man zypper implies that it won't, that rule would have been set by some default value, as the only way I could be said to have set it would be by the omission of any action to set it explicitly...
How does one set a rule to allow zypper up to change vendor?
edit /etc/zypp/zypp.conf change # solver.allowVendorChange = false
And would that allow it to change vendor on download error such as a bad checksum on the current vendor's copy of a package that is also available in another enabled repo?
no *Most* of this is discoverable by using the included docs and/or perusing the config files of the concerned apps. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2011-09-20 at 13:20 -0400, Joe(theWordy)Philbrook wrote:
Well if the priority level of each repo is set by default relative to the
No, default is 99. You choose a lower value to give a repo higher priority.
How does one set a rule to allow zypper up to change vendor?
I don't. I use YaST to make such changes.
And would that allow it to change vendor on download error such as a bad checksum on the current vendor's copy of a package that is also available in another enabled repo?
Not recomended. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk543SYACgkQtTMYHG2NR9WS0ACeIJNM5l8mKlwEDOr4eOUBIVcP FgIAnAt7ahypcNi8nxPIRtbkCeIbDZhN =ffdB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
=> It would appear that on Sep 20, Carlos E. R. did say: -> It would appear that on Sep 20, Patrick Shanahan did say:
On Tuesday, 2011-09-20 at 13:20 -0400, Joe(theWordy)Philbrook wrote:
In which case, how would I go about assigning a different priority level?
=> No, default is 99. You choose a lower value to give a repo higher priority. -> zypper --help -> zypper mr --help -> zypper mr -p <some number> <repo> OK so Carlos (Who uses YaST) explains the logic of how the repos are prioritized, and Patrick lists the Zypper method of making the change... PERFECT Thanks to you both!
How does one set a rule to allow zypper up to change vendor?
=> I don't. I use YaST to make such changes. And yet this YaST user actualy cares if I use zypper correctly? ;-) -> edit /etc/zypp/zypp.conf -> change # solver.allowVendorChange = false Well that seems streight forward enough...
And would that allow it to change vendor on download error such as a bad checksum on the current vendor's copy of a package that is also available in another enabled repo?
=> Not recomended.
-> no
-> *Most* of this is discoverable by using the included docs and/or perusing
-> the config files of the concerned apps.
True. But in my defence I can only say that as a multi-Linux user, I'm not
always using OpenSuSE when I get a chance to read/reply to my mail... And
in that case neither "man zypper" nor "zypper --help" are available.
And that was the case when I responded to Carlos' comment on those two
particular "rules" {as he described them}. As it happened I'd never noticed
the bit on prioritization before, Nor prior to this thread did I know that
changeng "vendor" basicly meant changing repository.
Since I wasn't running OpenSuSE at that moment I tried a web seach...
And the (admittedly out dated) man file for zypper I found online didn't
seem to include a sectom on prioritizing a repo...
http://manpages.unixforum.co.uk/man-pages/linux/opensuse-10.2/8/zypper-man-p...
But in any case I thank both of you for the advice & information...
--
| ~^~ ~^~
| <*> <*> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2011-09-21 at 11:08 -0400, Joe(theWordy)Philbrook wrote:
And yet this YaST user actualy cares if I use zypper correctly? ;-)
I also use zypper now and then. I don't know all its tricks. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk56T3MACgkQtTMYHG2NR9XU6ACfSb5k7e52a4JhEE+0WHHXbscF O3gAoIJqS+iqnH3NOajidPuAekm6t8nh =DNmH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2011-09-21 at 22:56 +0200, I wrote:
On Wednesday, 2011-09-21 at 11:08 -0400, Joe(theWordy)Philbrook wrote:
And yet this YaST user actualy cares if I use zypper correctly? ;-)
I also use zypper now and then. I don't know all its tricks.
Also, most of those "rules" have effect on both programs. It is the manner the user interacts that is different. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk56ULoACgkQtTMYHG2NR9Wo/QCfQlVykosW7+ZWK0/dSBngnvB0 R3oAnA5cMj7ksJN0Jb/biq/ymgCnrI7T =vWhy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
J(tWdy)P wrote:
Hello. I'm a multi-Linux distro Multi-boot user. I have a strong preference for text based package managements systems that can be run when X isn't. Currently I have a better understanding of apt-get, pacman and equo from my Ubuntu, Arch, and Sabayon installations than I have of zypper.
As well as using the zypper command-line tool are you aware that you can also use YaST without having X running? There is an ncurses version called 'yast' whilst the X GUI version is 'yast2'. Not suggesting that zypper is a bad idea, just making sure you know other possibilities. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (7)
-
Carlos E. R. -
Dave Howorth -
Greg Freemyer -
J(tWdy)P -
Joe(theWordy)Philbrook
-
Marcus Meissner -
Patrick Shanahan