[zypp-devel] Trying to try out MediaAria2c handler...
Hi, I'd like to try out Gerards work, which he has built in the build service, branched from the zypp-devel project: home:gfarrasb:branches:zypp:svn/libzypp It builds on openSUSE 11.0. However, trying to install it I run into a number of dependency problems: Error: Missing Dependency: satsolver-tools = 0.10.4 is needed by package libzypp-5.7.0-3.1.i586 (home_gfarrasb_branches_zypp_svn) Error: Missing Dependency: libzypp.so.424 is needed by package yast2-pkg-bindings-2.16.40-0.2.i586 (installed) Error: Missing Dependency: libzypp.so.424 is needed by package yast2-gtk-2.16.14-1.2.i586 (installed) I would be able to deinstall the yast stuff, but I can't find a newer sat solver for 11.0. In fact, I can't find any satsolver-tools package in the build service: % osc search --package satsolver-tools No matches found for 'satsolver-tools' in packages So I thought you guys could shed some light on what could be done? What's the recommended procedure to use newer libzypp builds on 11.0? Thanks, Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
On Thu, Aug 28, 2008 at 09:51:46PM +0200, Peter Poeml wrote:
Error: Missing Dependency: satsolver-tools = 0.10.4 is needed by package libzypp-5.7.0-3.1.i586 (home_gfarrasb_branches_zypp_svn) [...] % osc search --package satsolver-tools No matches found for 'satsolver-tools' in packages
It turns out that "osc search" wasn't the best way to look for that package, because it is a subpackage which isn't seen in this way. I found the package in the zypp:svn project in the end, built for openSUSE 11.0 and I could installs it fine, together with libzypp, after deinstalling all yast packages. Now, embarrassingly, I have to admit I need instructions of the sort "how to use zypper for dummies". Every poor soul can type "yum update" and it'll work, but with zyppper I have tried all kind of things and none of them seems to work for me: zypper addservice 'http://download.opensuse.org/repositories/home:/poeml/openSUSE_11.0/' home_poeml zypper refresh zypper update zypper -t package update zypper update -t package But looking into zypper.log as well as the Apache logs at download.opensuse.org, I don't see a single bit of network access. What do I have to do? :-) Then, a disturbing fact I need to nitpick on is that zypper removing all my old kernels at the very top of its todo list: # zypper update -t package Reading installed packages... The following packages are going to be REMOVED: kernel-pae kernel-default kernel-default kernel-default kernel-default After the operation, 283.9 M will be freed. Continue? [YES/no]: Stano mentioned that this is fixed in Factory. I use zypper from zypp:svn. What do I need to do? Thanks Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Hi, this is with zypper-0.12.2-2.1 libzypp-5.7.0-1.1 from the zypp:svn project, openSUSE 11.0 build. There is an inconsistency, zypper claims no repository is enabled, while it is shown enabled with another command: # zypper refresh There are no enabled repositories defined. Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories. # zypper sl # | Alias | Name | Enabled | Refresh --+------------+------------+---------+-------- 1 | home_poeml | home_poeml | Yes | No Known bug? Bug report? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Dňa Friday 29 August 2008 11:17:53 Peter Poeml ste napísal:
Hi,
this is with zypper-0.12.2-2.1 libzypp-5.7.0-1.1 from the zypp:svn project, openSUSE 11.0 build.
There is an inconsistency, zypper claims no repository is enabled, while it is shown enabled with another command:
Well, it's factory version, might be a bug.
# zypper refresh There are no enabled repositories defined. Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories. # zypper sl # | Alias | Name | Enabled | Refresh --+------------+------------+---------+-------- 1 | home_poeml | home_poeml | Yes | No
zypper lr? Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Aug 29, 2008 at 11:23:41AM +0200, Stanislav Visnovsky wrote:
Dňa Friday 29 August 2008 11:17:53 Peter Poeml ste napísal:
Hi,
this is with zypper-0.12.2-2.1 libzypp-5.7.0-1.1 from the zypp:svn project, openSUSE 11.0 build.
There is an inconsistency, zypper claims no repository is enabled, while it is shown enabled with another command:
Well, it's factory version, might be a bug.
# zypper refresh There are no enabled repositories defined. Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories. # zypper sl # | Alias | Name | Enabled | Refresh --+------------+------------+---------+-------- 1 | home_poeml | home_poeml | Yes | No
zypper lr?
Is empty. I thought sl and rl (uhm... lr) is the same. I had typed sl, which suggested me to use the "addservices" command next. Wait, did "sl" have a different meaning in the past? zypper on SLE10 only has s* commands, no r* commands. Is that a good idea?? Anyway, this helped me. Thanks for explaining the difference. I always appreciate if you take the time for this. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Dňa Friday 29 August 2008 12:02:58 Peter Poeml ste napísal:
On Fri, Aug 29, 2008 at 11:23:41AM +0200, Stanislav Visnovsky wrote:
Dňa Friday 29 August 2008 11:17:53 Peter Poeml ste napísal:
Hi,
this is with zypper-0.12.2-2.1 libzypp-5.7.0-1.1 from the zypp:svn project, openSUSE 11.0 build.
There is an inconsistency, zypper claims no repository is enabled, while it is shown enabled with another command:
Well, it's factory version, might be a bug.
# zypper refresh There are no enabled repositories defined. Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories. # zypper sl # | Alias | Name | Enabled | Refresh --+------------+------------+---------+-------- 1 | home_poeml | home_poeml | Yes | No
zypper lr?
Is empty.
I thought sl and rl (uhm... lr) is the same.
I had typed sl, which suggested me to use the "addservices" command next.
Wait, did "sl" have a different meaning in the past? zypper on SLE10 only has s* commands, no r* commands. Is that a good idea??
Not sure given your comments... The SLE10 meaning should be active in rug compatibility mode only. I'm afraid we need to wait for zypper maintainer to get back from vacation.
Anyway, this helped me. Thanks for explaining the difference. I always appreciate if you take the time for this.
Welcome! Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stanislav Visnovsky wrote:
Dňa Friday 29 August 2008 12:02:58 Peter Poeml ste napísal:
On Fri, Aug 29, 2008 at 11:23:41AM +0200, Stanislav Visnovsky wrote:
Dňa Friday 29 August 2008 11:17:53 Peter Poeml ste napísal:
Hi,
this is with zypper-0.12.2-2.1 libzypp-5.7.0-1.1 from the zypp:svn project, openSUSE 11.0 build.
There is an inconsistency, zypper claims no repository is enabled, while it is shown enabled with another command: Well, it's factory version, might be a bug.
# zypper refresh There are no enabled repositories defined. Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories. # zypper sl # | Alias | Name | Enabled | Refresh --+------------+------------+---------+-------- 1 | home_poeml | home_poeml | Yes | No zypper lr? Is empty.
I thought sl and rl (uhm... lr) is the same.
not after 11.0! sl will list services, lr ordinary repos (similar to rug's catalogs).
I had typed sl, which suggested me to use the "addservices" command next.
Wait, did "sl" have a different meaning in the past? zypper on SLE10 only has s* commands, no r* commands. Is that a good idea??
Not sure given your comments...
The SLE10 meaning should be active in rug compatibility mode only.
I'm afraid we need to wait for zypper maintainer to get back from vacation.
Hi there, i'm finally back :O) The situation goes like this: - rug's service-* command were just aliases for the *repo commands of zypper until 11.0 - now that zypper is getting support for services, new *service commands have been added, and the rug's service-* commands are now aliases for these new commands. - the support for *service command still needs to be polished and well-integrated with the existing *repo commands. For example, 'zypper addservice http://an.url.to/an/ordinary/repo foo' should probably just add an ordinary repo, if that URL does not contain repoindex. Or to complain upon refresh. Things like these are still not clear and need to be worked out. cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Tue, Sep 02, 2008 at 06:08:19PM +0200, Jan Kupec wrote:
Hi there, i'm finally back :O) The situation goes like this:
- rug's service-* command were just aliases for the *repo commands of zypper until 11.0 - now that zypper is getting support for services, new *service commands have been added, and the rug's service-* commands are now aliases for these new commands.
Why's there a different interface? Can't zypper just use the repo command set and use type "service" for a service? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Schroeder wrote:
On Tue, Sep 02, 2008 at 06:08:19PM +0200, Jan Kupec wrote:
Hi there, i'm finally back :O) The situation goes like this:
- rug's service-* command were just aliases for the *repo commands of zypper until 11.0 - now that zypper is getting support for services, new *service commands have been added, and the rug's service-* commands are now aliases for these new commands.
Why's there a different interface? Can't zypper just use the repo command set and use type "service" for a service?
Because it's quite different thing - it's a repository index, which serves for auto-managing repositories on your machine - it's one level higher in the repo management. You can't e.g. specify a service as the --repo (well, that could be transformed into individual repos), you still need two different command for listing services and listing repos (standalone and the ones from services), and you still need to manipulate both the services, and the repos they contain, which you can't do using one command set (how would you e.g. disable a repository within a service?). Comments are welcome, we still have time to change this. jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Wed, Sep 03, 2008 at 01:08:40PM +0200, Jan Kupec wrote:
Michael Schroeder wrote:
On Tue, Sep 02, 2008 at 06:08:19PM +0200, Jan Kupec wrote:
Hi there, i'm finally back :O) The situation goes like this:
- rug's service-* command were just aliases for the *repo commands of zypper until 11.0 - now that zypper is getting support for services, new *service commands have been added, and the rug's service-* commands are now aliases for these new commands.
Why's there a different interface? Can't zypper just use the repo command set and use type "service" for a service?
Because it's quite different thing - it's a repository index, which serves for auto-managing repositories on your machine - it's one level higher in the repo management.
You can't e.g. specify a service as the --repo (well, that could be transformed into individual repos), you still need two different command for listing services and listing repos (standalone and the ones from services), and you still need to manipulate both the services, and the repos they contain, which you can't do using one command set (how would you e.g. disable a repository within a service?).
Compatibility!! You can treat ordinary repositories as trivial services with a single repo that is always subscribed. That way, "service" commands will keep working on repos. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Martin Vidner wrote:
On Wed, Sep 03, 2008 at 01:08:40PM +0200, Jan Kupec wrote:
Michael Schroeder wrote:
On Tue, Sep 02, 2008 at 06:08:19PM +0200, Jan Kupec wrote:
Hi there, i'm finally back :O) The situation goes like this:
- rug's service-* command were just aliases for the *repo commands of zypper until 11.0 - now that zypper is getting support for services, new *service commands have been added, and the rug's service-* commands are now aliases for these new commands. Why's there a different interface? Can't zypper just use the repo command set and use type "service" for a service? Because it's quite different thing - it's a repository index, which serves for auto-managing repositories on your machine - it's one level higher in the repo management.
You can't e.g. specify a service as the --repo (well, that could be transformed into individual repos), you still need two different command for listing services and listing repos (standalone and the ones from services), and you still need to manipulate both the services, and the repos they contain, which you can't do using one command set (how would you e.g. disable a repository within a service?).
Compatibility!!
You can treat ordinary repositories as trivial services with a single repo that is always subscribed. That way, "service" commands will keep working on repos.
Agreed, that's how we want it (should already be working like that). But this is a different topic from what Michael asked. j. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Wed, Sep 03, 2008 at 01:08:40PM +0200, Jan Kupec wrote:
Michael Schroeder wrote:
Why's there a different interface? Can't zypper just use the repo command set and use type "service" for a service?
Because it's quite different thing - it's a repository index, which serves for auto-managing repositories on your machine - it's one level higher in the repo management.
Maybe it's different internally, but the interface looks very similar.
You can't e.g. specify a service as the --repo (well, that could be transformed into individual repos),
But that would be a feature for the future, wouldn't it? I.e. "install a package from a service".
you still need two different command for listing services and listing repos (standalone and the ones from services),
"zypper lr -t service"?
and you still need to manipulate both the services, and the repos they contain, which you can't do using one command set (how would you e.g. disable a repository within a service?).
My suggestion was to make "zypper lr" show both the services and the repositories. You would disable a repo within a service like with your implementation. I must admin that I don't know the exact specification of services (is there some documentation), so maybe I'm missing something. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Aug 29, 2008 at 11:10:28AM +0200, Peter Poeml wrote:
# zypper update -t package Reading installed packages...
The following packages are going to be REMOVED: kernel-pae kernel-default kernel-default kernel-default kernel-default
After the operation, 283.9 M will be freed. Continue? [YES/no]:
Stano mentioned that this is fixed in Factory. I use zypper from zypp:svn. What do I need to do?
You need to tell zypper that it's ok to have multiple versions of the kernel. I think it's done by adding multiversion = kernel-pae, kernel-default to /etc/zypp/zypp.conf, but I'm not sure. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Aug 29, 2008 at 02:37:22PM +0200, Michael Schroeder wrote:
On Fri, Aug 29, 2008 at 11:10:28AM +0200, Peter Poeml wrote:
# zypper update -t package Reading installed packages...
The following packages are going to be REMOVED: kernel-pae kernel-default kernel-default kernel-default kernel-default
After the operation, 283.9 M will be freed. Continue? [YES/no]:
Stano mentioned that this is fixed in Factory. I use zypper from zypp:svn. What do I need to do?
You need to tell zypper that it's ok to have multiple versions of the kernel. I think it's done by adding
multiversion = kernel-pae, kernel-default
to /etc/zypp/zypp.conf, but I'm not sure.
Cheers, Michael.
Thanks for the hint, it looks promising. Indeed the conf file has a comment version of that. It doesn't seem to have any effect though. Bug? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Dňa Friday 29 August 2008 22:58:59 Peter Poeml ste napísal:
On Fri, Aug 29, 2008 at 02:37:22PM +0200, Michael Schroeder wrote:
On Fri, Aug 29, 2008 at 11:10:28AM +0200, Peter Poeml wrote:
# zypper update -t package Reading installed packages...
The following packages are going to be REMOVED: kernel-pae kernel-default kernel-default kernel-default kernel-default
After the operation, 283.9 M will be freed. Continue? [YES/no]:
Stano mentioned that this is fixed in Factory. I use zypper from zypp:svn. What do I need to do?
You need to tell zypper that it's ok to have multiple versions of the kernel. I think it's done by adding
multiversion = kernel-pae, kernel-default
to /etc/zypp/zypp.conf, but I'm not sure.
Cheers, Michael.
Thanks for the hint, it looks promising. Indeed the conf file has a comment version of that. It doesn't seem to have any effect though. Bug?
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata. For those packages then libzypp will use the multiversion value into account. HTH Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stanislav Visnovsky schrieb:
Dňa Friday 29 August 2008 22:58:59 Peter Poeml ste napísal:
On Fri, Aug 29, 2008 at 02:37:22PM +0200, Michael Schroeder wrote:
On Fri, Aug 29, 2008 at 11:10:28AM +0200, Peter Poeml wrote:
# zypper update -t package Reading installed packages...
The following packages are going to be REMOVED: kernel-pae kernel-default kernel-default kernel-default kernel-default
After the operation, 283.9 M will be freed. Continue? [YES/no]:
Stano mentioned that this is fixed in Factory. I use zypper from zypp:svn. What do I need to do?
You need to tell zypper that it's ok to have multiple versions of the kernel. I think it's done by adding
multiversion = kernel-pae, kernel-default
to /etc/zypp/zypp.conf, but I'm not sure.
Cheers, Michael.
Thanks for the hint, it looks promising. Indeed the conf file has a comment version of that. It doesn't seem to have any effect though. Bug?
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
For those packages then libzypp will use the multiversion value into account.
HTH
Stano
This flag does work for installation only. mls has added the delete feature to the SAT solver last week too. I will update libzypp today. Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 10:09:32AM +0200, Stefan Schubert wrote:
This flag does work for installation only. mls has added the delete feature to the SAT solver last week too. I will update libzypp today.
Unfortunately, build of zypp:svn fails for openSUSE_11.0 because zypper has a requires on satsolver-tools = 0.10.4, but there is satsolver-0.10.6.tar.bz2 being built so there is an expansion error in the build service. Short of this possibility I tried to work around by updating the package that zypper wants to update myself (--noscripts to keep my boot setup untouched). Shouldn't this be a possible workaround? My expectation being that zypper finds the kernels up to date and doesn't want to install kernels. However, I get the following, zypper now wants to *reinstall* the kernel. Why's that? # zypper up -t package Reading installed packages... The following package is going to be upgraded: apache2-mod_zrkadlo The following package is going to be reinstalled: kernel-default The following packages are going to be REMOVED: kernel-pae kernel-default kernel-default kernel-default kernel-default kernel-default Overall download size: 21.8 M. After the operation, 330.6 M will be freed. Continue? [YES/no]: n [ By the way, it would be very helpful if zypper would show package versions and the source where it comes from (repository). The output that it gives makes it very difficult to follow what it's trying to do. Is there a feature request for this? zypper has that information, I can find it in the zypper.log. What I don't find in the screen output and neither in the logs is information about requirements that pull packages in, or cause obsoletes or conflicts. That kind of information would be helpful too, for the die-hard admin. It would allow me to resolve problems. ] Thank you for your continued help! Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Hi, On Tue, 2 Sep 2008, Peter Poeml wrote:
[ By the way, it would be very helpful if zypper would show package versions and the source where it comes from (repository). The output that it gives makes it very difficult to follow what it's trying to do.
You want "zypper -v in ...".
What I don't find in the screen output and neither in the logs is information about requirements that pull packages in, or cause obsoletes or conflicts. That kind of information would be helpful too, for the die-hard admin. It would allow me to resolve problems. ]
That's available with environment variable settings where you can see satsolver resolving rules. That is _extremely_ verbose, but you can activate it by: ZYPP_FULLLOG=1 or (in case you only want the messages from SATsolver): ZYPP_LIBSAT_FULLLOG=1 Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Matz wrote:
Hi,
On Tue, 2 Sep 2008, Peter Poeml wrote:
[ By the way, it would be very helpful if zypper would show package versions and the source where it comes from (repository). The output that it gives makes it very difficult to follow what it's trying to do.
You want "zypper -v in ...".
See also Bug #389128
What I don't find in the screen output and neither in the logs is information about requirements that pull packages in, or cause obsoletes or conflicts. That kind of information would be helpful too, for the die-hard admin. It would allow me to resolve problems. ]
That's available with environment variable settings where you can see satsolver resolving rules. That is _extremely_ verbose, but you can activate it by:
Yup, it might be worth moving this kind of info the the default log, or to the upcoming 'package history' log, and/or to zypper -v in ... output (might also be another option). cheers, jano
ZYPP_FULLLOG=1
or (in case you only want the messages from SATsolver):
ZYPP_LIBSAT_FULLLOG=1
Ciao, Michael.
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Dňa Friday 29 August 2008 22:58:59 Peter Poeml ste napísal:
On Fri, Aug 29, 2008 at 02:37:22PM +0200, Michael Schroeder wrote:
multiversion = kernel-pae, kernel-default
Bug?
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
For those packages then libzypp will use the multiversion value into account.
Hm, if that features requires a mark in the metadata, it is not helpful. There is no way for local admins to influence the metadata, is there? Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Dňa Monday 01 September 2008 10:41:27 Peter Poeml ste napísal:
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Dňa Friday 29 August 2008 22:58:59 Peter Poeml ste napísal:
On Fri, Aug 29, 2008 at 02:37:22PM +0200, Michael Schroeder wrote:
multiversion = kernel-pae, kernel-default
Bug?
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
For those packages then libzypp will use the multiversion value into account.
Hm, if that features requires a mark in the metadata, it is not helpful. There is no way for local admins to influence the metadata, is there?
The point is that the package itself needs to be packaged the way it can be installed in parallel in multiple versions. Most of the packages are not and that would just give you rpm errors on file-level conflicts. If they are, they can be marked in the metadata properly. Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
No, that's not true. M. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Dňa Monday 01 September 2008 12:38:40 Michael Schroeder ste napísal:
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
No, that's not true.
Interesting, because above was the agreement when we discussed this. How is it then? Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 12:48:23PM +0200, Stanislav Visnovsky wrote:
D??a Monday 01 September 2008 12:38:40 Michael Schroeder ste napísal:
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
No, that's not true.
Interesting, because above was the agreement when we discussed this. How is it then?
You just put the packages in /etc/zypp/zypp.conf. Same as with yum or smart. M. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Dňa Monday 01 September 2008 13:06:04 Michael Schroeder ste napísal:
On Mon, Sep 01, 2008 at 12:48:23PM +0200, Stanislav Visnovsky wrote:
D??a Monday 01 September 2008 12:38:40 Michael Schroeder ste napísal:
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
No, that's not true.
Interesting, because above was the agreement when we discussed this. How is it then?
You just put the packages in /etc/zypp/zypp.conf. Same as with yum or smart.
OK. The metadata flag should be pre-requisite for the multiversion flag to be taken into account - that's my understanding. Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 12:48:23PM +0200, Stanislav Visnovsky wrote:
Dňa Monday 01 September 2008 12:38:40 Michael Schroeder ste napísal:
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
No, that's not true.
Interesting, because above was the agreement when we discussed this. How is it then?
The problem is that the metadata creators may not be aware, or this may be forgotten, or the need may arise for packages where nobody has thought about it, so what I really mandate is a way to specifiy this kind of configuration on the client side. If the kernels have not been marked as such so far, this only proves my point, doesn't it? :) Also, there is no need to worry about this IMO, because if a package isn't installable next to a previous version because of a file conflict, the installer will tell me about it anyway, or not? And a flag in the metadata doesn't fix any underlying problem. Furthermore, IMO it's more complicated than needed if it needs action on different ends. I have been using the feature with yum for 5 years now and I can say that the mechanism is useful in the real world in the form implemented there. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
Dňa Monday 01 September 2008 13:17:29 Peter Poeml ste napísal:
On Mon, Sep 01, 2008 at 12:48:23PM +0200, Stanislav Visnovsky wrote:
Dňa Monday 01 September 2008 12:38:40 Michael Schroeder ste napísal:
On Mon, Sep 01, 2008 at 09:36:42AM +0200, Stanislav Visnovsky wrote:
Maybe. The behavior should be that if the package can be installed in parallel in multiple versions, it must be marked so in the metadata.
No, that's not true.
Interesting, because above was the agreement when we discussed this. How is it then?
The problem is that the metadata creators may not be aware, or this may be forgotten, or the need may arise for packages where nobody has thought about it, so what I really mandate is a way to specifiy this kind of configuration on the client side.
True.
If the kernels have not been marked as such so far, this only proves my point, doesn't it? :)
Also, there is no need to worry about this IMO, because if a package isn't installable next to a previous version because of a file conflict, the installer will tell me about it anyway, or not? And a flag in the metadata doesn't fix any underlying problem.
No, file conflicts are by default not caught by libzypp as the file lists are not downloaded and parsed (except for specific file patterns). But there is also a problem that the package might not be installable in parallel even if there is no file conflict. Yes, that might be fixable by black-listing instead of white-listing in metadata (the current approach).
Furthermore, IMO it's more complicated than needed if it needs action on different ends. I have been using the feature with yum for 5 years now and I can say that the mechanism is useful in the real world in the form implemented there.
Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 01:45:52PM +0200, Stanislav Visnovsky wrote:
The problem is that the metadata creators may not be aware, or this may be forgotten, or the need may arise for packages where nobody has thought about it, so what I really mandate is a way to specifiy this kind of configuration on the client side.
True.
Okay, we agree. Good :-)
If the kernels have not been marked as such so far, this only proves my point, doesn't it? :)
Also, there is no need to worry about this IMO, because if a package isn't installable next to a previous version because of a file conflict, the installer will tell me about it anyway, or not? And a flag in the metadata doesn't fix any underlying problem.
No, file conflicts are by default not caught by libzypp as the file lists are not downloaded and parsed (except for specific file patterns).
This puzzles me, how does zypper deal with this? Does it detect file conflicts only when already in the middle of installing packages? This sounds dangerous, because it sounds as if package installation might abort in the middle of something.
But there is also a problem that the package might not be installable in parallel even if there is no file conflict. Yes, that might be fixable by black-listing instead of white-listing in metadata (the current approach).
Which problems, other than file conflicts, would that be? Could you elaborate? Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
On Mon, Sep 01, 2008 at 02:00:49PM +0200, Peter Poeml wrote:
This puzzles me, how does zypper deal with this?
Yum also doesn't do file conflicts, as the information needed for this is not present in the rpm-md metadata. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 02:03:39PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:00:49PM +0200, Peter Poeml wrote:
This puzzles me, how does zypper deal with this?
Yum also doesn't do file conflicts, as the information needed for this is not present in the rpm-md metadata.
It does - it always runs a test transaction before changing the system, which reliably detects them. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
On Mon, Sep 01, 2008 at 02:06:07PM +0200, Peter Poeml wrote:
On Mon, Sep 01, 2008 at 02:03:39PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:00:49PM +0200, Peter Poeml wrote:
This puzzles me, how does zypper deal with this?
Yum also doesn't do file conflicts, as the information needed for this is not present in the rpm-md metadata.
It does - it always runs a test transaction before changing the system, which reliably detects them.
Yeah, but this is after solving and downloading, which is way to late. M. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Mon, Sep 01, 2008 at 02:10:20PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:06:07PM +0200, Peter Poeml wrote:
On Mon, Sep 01, 2008 at 02:03:39PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:00:49PM +0200, Peter Poeml wrote:
This puzzles me, how does zypper deal with this?
Yum also doesn't do file conflicts, as the information needed for this is not present in the rpm-md metadata.
It does - it always runs a test transaction before changing the system, which reliably detects them.
Yeah, but this is after solving and downloading, which is way to late.
It's late, but not *too* late. It works. And I need to download the packages anyway, once the conflict is resolved. Of course, quicker would be nicer, but it's at least something. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, Sep 02, 2008 at 04:29:41PM +0200, Peter Poeml wrote:
On Mon, Sep 01, 2008 at 02:10:20PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:06:07PM +0200, Peter Poeml wrote:
On Mon, Sep 01, 2008 at 02:03:39PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:00:49PM +0200, Peter Poeml wrote:
This puzzles me, how does zypper deal with this?
Yum also doesn't do file conflicts, as the information needed for this is not present in the rpm-md metadata.
It does - it always runs a test transaction before changing the system, which reliably detects them.
Yeah, but this is after solving and downloading, which is way to late.
It's late, but not *too* late. It works. And I need to download the packages anyway, once the conflict is resolved.
How do you resolve the conflict? M. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Tue, Sep 02, 2008 at 04:35:06PM +0200, Michael Schroeder wrote:
On Tue, Sep 02, 2008 at 04:29:41PM +0200, Peter Poeml wrote:
On Mon, Sep 01, 2008 at 02:10:20PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:06:07PM +0200, Peter Poeml wrote:
On Mon, Sep 01, 2008 at 02:03:39PM +0200, Michael Schroeder wrote:
On Mon, Sep 01, 2008 at 02:00:49PM +0200, Peter Poeml wrote:
This puzzles me, how does zypper deal with this?
Yum also doesn't do file conflicts, as the information needed for this is not present in the rpm-md metadata.
It does - it always runs a test transaction before changing the system, which reliably detects them.
Yeah, but this is after solving and downloading, which is way to late.
It's late, but not *too* late. It works. And I need to download the packages anyway, once the conflict is resolved.
How do you resolve the conflict?
There can be no single answer to this. That depends on the conflict. Possible resolutions range from - deciding for one of the conflicting packages, - deinstalling something that conflicts, - updating a package that should be updated but isn't, so far (maybe from elsewhere), - fixing my installation sources if they don't fit together somehow, - simply forcing the install when I know the conflict is harmless or I am willing to enforce it to fixing the broken package upstream, or reporting a bug. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
participants (7)
-
Jan Kupec -
Martin Vidner -
Michael Matz -
Michael Schroeder -
Peter Poeml -
Stanislav Visnovsky -
Stefan Schubert