Re: [opensuse-factory] Locking packages ...
On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: Is that not the same as we have now? Henne No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. For example, right now if you install MPlayer from packman, mplayer gets locked, because vendor != SUSE, and wont be changed even if there is an updated from the same packman! -- Duncan Mac-Vicar Prett Novell :: SUSE RD, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Friday 20 April 2007 12:00:25 skrev Duncan Mac-Vicar Prett: On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: Is that not the same as we have now? Henne No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. For example, right now if you install MPlayer from packman, mplayer gets locked, because vendor != SUSE, and wont be changed even if there is an updated from the same packman! I like this suggestion a lot. Especially if combined with an obvious way of showing that versions from more than one vendor are available - without requiring the user to actively go to Versions to check. Be that an '*', a [+] or whatever. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: Is that not the same as we have now? No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != what you have now a.k.a. SUSE after a install Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Schlander schreef: Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level. I think this is a quite common usecase actually. Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan. Amarok (most people will want Guru, BS version is crippled wrt. database support I believe) This is correct.. Ktorrent (most people will want Guru, BS-version crippled wrt. DHT) Digikam (most people will want the backported version cuz the packman version causes problems with some libs) K3b (sometimes packman has had development builds, which not all will want) Alsa (if your sounds working nicely why would you want to do a risky upgrade automatically for something like that). Agree.. To name a few very popular packages where I'm aware of problems (presently or in the past). Yes... I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're updating to something alphaish. You hit the nail on the head - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 release 45.2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKNnQX5/X5X6LpDgRAscaAJ4pV2ArqjT9j27Lf862sthlrD58bACgjmee 4e2eW13aSduu9cXHVvoLGFc= =h5Gz -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Friday 20 April 2007 13:13:04 Henne Vogelsang wrote: I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != what you have now a.k.a. SUSE after a install Of course not, because the package from a 3er party is seen as a replacement, not as an upgrade. You can always manually (click twice) upgrade (or replace) one vendor to another, and then the semantics are the same, the packages will be automatically updated if newer versions from your new vendor are available. If it does not work like I say, it basically means cou could be playing ping pong across 2 or 3 vendors as newer packages come out, or you do it like now, which sucks. Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system. Regards, Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On 4/20/07, Henne Vogelsang [EMAIL PROTECTED] wrote: Hi, On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: Is that not the same as we have now? No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version. I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != what you have now a.k.a. SUSE after a install User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo. _ Benjamin Weber - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level. I think this is a quite common usecase actually. Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan. Amarok (most people will want Guru, BS version is crippled wrt. database support I believe) Ktorrent (most people will want Guru, BS-version crippled wrt. DHT) Digikam (most people will want the backported version cuz the packman version causes problems with some libs) K3b (sometimes packman has had development builds, which not all will want) Alsa (if your sounds working nicely why would you want to do a risky upgrade automatically for something like that). To name a few very popular packages where I'm aware of problems (presently or in the past). I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're updating to something alphaish. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Friday 20 April 2007 14:42:42 Henne Vogelsang wrote: The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? No, especially with the build service, you never know what package will appear there (in a specific repo) you just dont want to use. The packages in a repo are not a constant you agree on. Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Friday, April 20, 2007 at 15:06:34, Martin Schlander wrote: Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level. I think this is a quite common usecase actually. Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan. Amarok (most people will want Guru, BS version is crippled wrt. database support I believe) [...] And you should decide these on a package basis (setting something to taboo if you definately dont want it). This however should have nothing to do with the general policy. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alberto Passalacqua schreef: Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system. Here i agree, it happened to me on 100, which became useless,(had to reinstall, choose 101),on 101, which became instable, but still worked, and also on 102. the retailversion, which took about 3 hours to upgrade a few pkgs, and all kind of mysterious happenings flew over the screen and got me realy worried,(it costs a day to get everything back to normal after wrekking an OS..) and when it was done, I thought: this is the last time like this!, but after finishing, the system was and still is stable as a house( but i still do not know what realy happened there...a feeling i personaly don't like at all..) I am carefull now with other pkgs except the ones I realy need: Samba,(a story on its own..) libxine, w32codec-all.. Only factory upgrades? No problem at all... Regards, Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 release 45.2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKNjqX5/X5X6LpDgRAo+XAKCNn3YZ+uj4/6nMfNphGEvaocZHhQCeIibT JyRZFxOwLOo1FQtrBaSaVsk= =tuQb -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 M9. schreef: Alberto Passalacqua schreef: Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system. I am carefull now with other pkgs except the ones I realy need: Samba,(a story on its own..) libxine, w32codec-all.. ..forgot libdvdcss, i allways have a tar lying around to compile Only factory upgrades? No problem at all... Regards, Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 release 45.2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKN1fX5/X5X6LpDgRAryVAJ90G6SlnPfQcF7fr1Fasz8tKlNYqgCgwJ5z hDllIDUtM21LVcL4A8eQwVQ= =Kdax -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On 20-04-2007 at 16:06, Martin Schlander [EMAIL PROTECTED] wrote: I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're I think the whole thing is going in the right direction now: have upgrades happen only withing the same vendor. This would allow me to add packman again as a source (hmm. just wonder: do I need it? anyhow I can just copy thge required RPMs down). But this gives a new 'problem' for the BS repos: as far as I know, they're all by the same vendor. Maybe the repo name should be added there, so that 'inter-repo-updates' (so from one repo to another' don't happen. Example: I have GNOME:UNSTABLE in my source list. out of GNOME:UNSTABLE I link some to my home repo, with some patches. Both are in my source list. I most likely will want to keep the packages from where I installed them until further configuration. A notice, that another subscribed repo provides a newer version could thus be interesting... but that's another story. Dominique -- TMF is a global management and accounting outsourcing firm with 72 offices in 56 countries and over 2,000 professionals (February 2007). TMF is expanding rapidly throughout the world. Learn more about our unique network and our services and visit our website at www.tmf-group.com. The information contained in this e-mail communication is confidential and solely intended for the person to whom it is addressed. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to notify the sender and to destroy the original e-mail communication. TMF is neither liable for the correct and complete transmission of the information contained in this e-mail communication nor for any delay in its receipt. This footnote also confirms that this email message has been checked for the presence of computer viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Friday 20 April 2007 14:24:53 skrev Benji Weber: I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version. I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != what you have now a.k.a. SUSE after a install User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo. I agree. But Henne makes a good point too, and I have no doubt that many, many users will be very unhappy if upgrade all-behaviour is made more difficult for them - even if it is for their own good ;-) Many already want it to be even easier than now - for example by opensuseupdater supporting it. Maybe it could be possible to have two options. Only do semi-automatic updates from same vendor (default) and Do semi-automatic upgrade of any package where newer version is avaialable, (break-my-SUSE) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Friday, April 20, 2007 at 13:24:53, Benji Weber wrote: On 4/20/07, Henne Vogelsang [EMAIL PROTECTED] wrote: On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: Is that not the same as we have now? No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level. Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version. The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != what you have now a.k.a. SUSE after a install User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo. Automatic inter-vendor updates are what people expect to happen. Its what we currently do not deliver with yast but with all other package managers. There it works fine since ages. Why would we prohibit it (again)? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Exactly, so for crippled packages, you want to switch vendor, and keep upgrading from the same vendor. If you lock them like now, you dont get upgrades If you allow inter vendor upgrades, if a crppled version from another vendor has a newer version, it will be replaced. I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules) is much more simple and consistant. -- Duncan Mac-Vicar Prett Novell :: SUSE RD, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules) is much more simple and consistant. Its better, a little bit saner. I would prefer not to upgrade by default. You dont need to upgrade either when there is a new version of a package in packman either. Specialy when there are some cvs builds, experimental stuff, that can break easily. And as people said, just because you want codecs, doesnt mean you want to install alsa and lots of other core packages available in packman for some reason. Henne´s proposal will increase upgraditis. We dont need that. Its enough clueless people breaking their sytems with xgl, compiz and beryl. Marcio --- druid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Druid schreef: I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules) is much more simple and consistant. Its better, a little bit saner. I would prefer not to upgrade by default. You dont need to upgrade either when there is a new version of a package in packman either. Specialy when there are some cvs builds, experimental stuff, that can break easily. And as people said, just because you want codecs, doesnt mean you want to install alsa and lots of other core packages available in packman for some reason. Henne´s proposal will increase upgraditis. We dont need that. Its enough clueless people breaking their sytems with xgl, compiz and beryl. This is not realy correct, if a system has to be improved, in this case the way to update/grade, this feature has to be tested vigourously, i would not want to call this behaviour 'upgraditis' ...in this case.. A way has to be found, to upgrade from url, without to have to be afraid to loose a goodworking system... INTERMEZZO I guess that everyone has his/her own taste according the look and feel of his/her Desktops. So am I liking one specific transparent sys-monitor, which comes with caramba: i-cons-sysres. In the upper-right corner of the screen (you can hang it where-ever you like..)it shows me CPU, RAM and swap load consumption, little things i want to know if the sys slows down.(top open on another desktop to find the cause..) I do not need a dominant gui, just the figures is enough. But caramba's support stopped somehow, and as KDE loads all apps i have open when i shut down,(very nice feature btw..) it now stopped to load the monitor (and Also Amarok (after a Guru update), and i have to load them by hand...shame..) As I have all the apps I use getting loaded on start-up, the start-up time is a little longer, but everything should be ready when i come back... But now corn has to ask everytime for validating the mailserver-certificate, and when i answer 'accept forever', every session this is asked, for 2 mailboxes x 4 buttons to push? These things make me dislike an ap, (might be a bug..), makes me decide to shut it off..(or get an update..if there was one..) Also, still the time nessesary for reading the metadata is much too long, and that way updating, or installing an app, takes too much time (What happened to the clever discussion about this subject some weeks ago?) (just little annoyances, making the experience a little less fun, that is all..) I like SuSE very much, installed the 102 32Bits retailversion on a U-Buddy yesterday. (barebone) P4 2.66GHz, 1024MB Ram, 160GB 2,5 IDE HDD, which has to gonna be my 'car-pc', for in the camper, USB GPS for the 'tomtom' and a 12 touchscreen (second-hand, has to be 'rubberized' open steel version), come to it, doing this all by myself, save me about 600,- euro, minimum. The idea to have lot of music, good movies, and all my apps while traveling makes me feel very 'complete'.. Marcio --- druid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.8-01-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 release 45.4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKQ6XX5/X5X6LpDgRAhmfAJ4/fJKf9O05zjRulpKK04zEvLnrMgCg3/+b 6x8e2YU0vAOFgBZEndqsicw= =Po9L -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
This is not realy correct, if a system has to be improved, in this case the way to update/grade, this feature has to be tested vigourously, i would not want to call this behaviour 'upgraditis' ...in this case.. You wouldnt call but it is. And who said all repositories contains tested packages? A way has to be found, to upgrade from url, without to have to be afraid to loose a goodworking system... That of course is a non sense, as it depends on the repository, not on the lock method, package manager, or the user. If you are afraid of losing a good working system, you should isntall waht you want after installation, and never ever touch the package manager again. Thats the way you wont never lose a good working system. In fact, if people did this more often, they would break much much less their installations Marcio --- druid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Thursday, April 19, 2007 at 00:18:56, Duncan Mac-Vicar P. wrote: On Wednesday 18 April 2007 11:23:12 am Henne Vogelsang wrote: Can you specify inter-vendor upgrades please? If you have MPlayer with vendor Foo the solver don't select Mplayer vendor Bar as a upgrade candidate even if it is newer unless it is a user explicit transaction Is that not the same as we have now? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henne Vogelsang wrote: On Tuesday, April 17, 2007 at 15:17:02, Klaus Kaempf wrote: * Henne Vogelsang [EMAIL PROTECTED] [Apr 17. 2007 15:07]: On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. Proposals anyone ? Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already. +1 Can you detail on how this proposal relates to the mentioned use-cases ? The first usecase is not really a realworld usecase because updates usualy dont include extra repos (if they would it would be no other usecase then the second). So with or without the lock you run into manual intervention. Right. That use case is more for a production server or an enterprise desktop and such. And there, you wouldn't add 3rd party repositories in the first place. For the maintenance case either you, as third party vendor, decide that you want to use the openSUSE updates (only increment %release by .0) even if they dont provide the same functionality or you prevent the updates from ever beeing newer (increment %release by 1). [...] All 3rd party repos i am aware of already do that because they support more package-managers than the yast one. And most of them strictly work on basis of rpmvercomp. Exactly. smart, yum, apt don't have such an automatic locking scheme (smart does have explicit locks though, even based on expressions, such as smart flag --set lock 'foobar = 1.0.1', and they work on installed and non-installed packages) so as packagers, we have to take care it works properly anyhow, without the black magic of automatic locks. At the very least, one should be able to turn it off in YaST2 and IMHO it should be turned off by default in openSUSE (maybe turn it on by default in SLE*). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ [EMAIL PROTECTED] [EMAIL PROTECTED] _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFGJb/Tr3NMWliFcXcRAsXOAJ4n1TqmAQfmvWsPm5bt5A7lC+1MtACfUwdj nxEpgxRz/AnPiiCkAF0c0nE= =pOAO -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Klaus Kaempf [EMAIL PROTECTED] writes: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. [...] Proposals anyone ? I still believe third parties (all of them) must learn not to touch the /usr, /var, etc. hierarchies. This includes the RPM database. That's probably a long term goal. For the time being, by default our tools should not update packages if the vendors are different. We must ask the user first or offer --force switches to command line tools. We also should ask whether some kind of update or a uninstall/install procedure is wanted. -- Karl Eichwalder RD / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Tuesday 17 April 2007 02:56:30 pm Klaus Kaempf wrote: Hi, bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. my proposal: - get rid of everything we have now. - don't allow automatic (only user transacted) inter-vendor upgrades (solves usecase 2) For the future: - implement a simple text list with package patterns that gets read from /etc. The challenge here is that it breaks the current UI lock concept (one package can be locked by more than one pattern). Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Wednesday, April 18, 2007 at 10:25:36, Duncan Mac-Vicar P. wrote: On Tuesday 17 April 2007 02:56:30 pm Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. my proposal: - get rid of everything we have now. - don't allow automatic (only user transacted) inter-vendor upgrades (solves usecase 2) Can you specify inter-vendor upgrades please? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Tuesday 17 April 2007 14:56:30 skrev Klaus Kaempf: Package locks try to provide a solution for the following use-cases Proposals anyone ? First of all I think these benefits are far outweighed by the problems the locks cause. So in my view the auto-locking could be just removed. Worst case a few people lose some functionaly temporarily. They would always be able to downgrade again if they have issues. And after trying that a couple of times they'll hopefully learn to pay attention to what they upgrade. But of course it's a valid point. For example you install Pascal's nice ktorrent package - and if you don't pay attention when updating you might get the crippled one from OBS with no DHT. Don't know if this could be taken care of with some versioning conventions, that could perhaps ensure that 3rd party packages are always considered newer. One thing that could possibly diminish the problems that having no locks could cause, and at the same time solve a different issue, would be if it was somehow made more apparent in sw_single when more versions of a package are available. In the present state the user has to actively go to the versions tab and check. In the Smart-gui all packages are listed as individual packages even if they're different versions of the same package. Maybe sw_single could be made to behave in a way that's a kind of compromise between the two radical approaches. Maybe the list could have some kind of tree-format, like with folders - and a little [+] showing that there are actually more versions of this package avaialable. Maybe it should only be done in case there are packages available from different vendors - otherwise it could become messy on x86_64 (biarch) systems. Hopefully if people are informed that more versions are available they'll think twice about which they update to. Another issue is that if you update using sw_single - Package - All packages - Update if newer version is available the locks are disregarded anyway. So in the ktorrent example you are very likely to have your guru-package replaced with the OBS-package despite the lock. If there were no locks at all, this way of updating could assume the user actively locked locked packages, and therefore respect the locks. The way it is now, whether Pascals package is locked or not, it will be updated if I use this method of updating. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. Proposals anyone ? Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
* Henne Vogelsang [EMAIL PROTECTED] [Apr 17. 2007 15:07]: Hi, On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. Proposals anyone ? Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already. Can you detail on how this proposal relates to the mentioned use-cases ? Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Tuesday, April 17, 2007 at 15:17:02, Klaus Kaempf wrote: * Henne Vogelsang [EMAIL PROTECTED] [Apr 17. 2007 15:07]: On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. Proposals anyone ? Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already. Can you detail on how this proposal relates to the mentioned use-cases ? The first usecase is not really a realworld usecase because updates usualy dont include extra repos (if they would it would be no other usecase then the second). So with or without the lock you run into manual intervention. For the maintenance case either you, as third party vendor, decide that you want to use the openSUSE updates (only increment %release by .0) even if they dont provide the same functionality or you prevent the updates from ever beeing newer (increment %release by 1). Most even use some extra chars in %release which is very stupid because it follows no scheme you could catch in a version comparison, but nevertheless this is the kind of the standard (for other reasons than version comparison too e.g. easily identify packages from the 3rd party repo.) All 3rd party repos i am aware of already do that because they support more package-managers than the yast one. And most of them strictly work on basis of rpmvercomp. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Am Dienstag, 17. April 2007 schrieb Henne Vogelsang: On Tuesday, April 17, 2007 at 15:17:02, Klaus Kaempf wrote: * Henne Vogelsang [EMAIL PROTECTED] [Apr 17. 2007 15:07]: On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. Proposals anyone ? Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already. Can you detail on how this proposal relates to the mentioned use-cases ? The first usecase is not really a realworld usecase because updates usualy dont include extra repos (if they would it would be no other usecase then the second). So with or without the lock you run into manual intervention. For the maintenance case either you, as third party vendor, decide that you want to use the openSUSE updates (only increment %release by .0) even if they dont provide the same functionality or you prevent the updates from ever beeing newer (increment %release by 1). Most even use some extra chars in %release which is very stupid because it follows no scheme you could catch in a version comparison, but nevertheless this is the kind of the standard (for other reasons than version comparison too e.g. easily identify packages from the 3rd party repo.) All 3rd party repos i am aware of already do that because they support more package-managers than the yast one. And most of them strictly work on basis of rpmvercomp. But sometimes it would be nice to have some form of locking. For example, at the moment using KDE:Backprots and Packman togehter does'nt work if you are using digikam. It is likely in such cases if you can restrict the installation of digikam and some of the libraries it depends on to one of both repositories (I know no reason, why packman should provide digikam at all, but that's another story). Some time ago the same problem existed with k3b, which is now resolved by following the KDE:Backports release of k3b more closely. There is no need for locking, if all repositories are perfectly maintained, but thst's not reality. Locking would allow to work around such problems without manaual intervention on each package update. Cheers Herbert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Tuesday 17 April 2007 23:13:12 skrev Herbert Graeber: But sometimes it would be nice to have some form of locking. For example, at the moment using KDE:Backprots and Packman togehter does'nt work if you are using digikam. Noone wants to remove the functionality completely. Only the automatic locking with no user interaction is being discussed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hello, on Dienstag, 17. April 2007, Klaus Kaempf wrote: bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. [...] The current solution to the above scenarious is to group packages based on their vendor attribute. Can you tell us some details? My impression always was that non-SUSE packages are always locked. Or did I miss some details? Packages from unknown vendors are auto-protected in order to prevent unwanted replacements. This is a very effective but also very limited solution. Proposals anyone ? IMHO, it's impossible to solve the usecases you posted automatically. Therefore, I'd like to have a dialog like Package updates - change vendor? You have installed package foo from $VENDOR, but there's a newer version available from $OTHER_VENDOR. What do you want to do? [Install package from $OTHER_VENDOR] [keep package from $VENDOR] [x] remember decicion for this package [x] remember decicion for vendor $VENDOR [x] remember decicion for all vendors So you would have the best of every solution: - no automatic cross-vendor that could remove some features - no package locks, normal dependency solving is possible - the user knows what's going on - seems to be really important because both the lock all and lock none method seem to imply that the user is surprised[tm] sooner or later Yes, it's another dialog to answer - but it's better than any automatic decision nobody really likes. Regards, Christian Boltz -- * Linux Viruscan. Windows 95 found. Remove it? (y/n) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Tuesday 17 April 2007 18:43, Christian Boltz wrote: Package updates - change vendor? You have installed package foo from $VENDOR, but there's a newer version available from $OTHER_VENDOR. What do you want to do? [Install package from $OTHER_VENDOR] [Install package from $VENDOR] [keep package from $VENDOR] [x] remember decicion for this package [x] remember decicion for vendor $VENDOR [x] remember decicion for all vendors This would be clear for most users. The other useful feature would be to have list of remembered status, to be able to revert decision by removing package fro the list. -- Regards, Rajko. http://en.opensuse.org/Portal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
