Bug 368104

A short summary of what pkg-bindings do:

Pkg::TargetInit():

- zypp_ptr()->initializeTarget(r) // r = "/mnt" in this case,
  // "false" is an unused historical parameter
- zypp_ptr()->target()->load()
- remember the root, every zypp::RepoManager object which is later created uses this root path

Pkg::TargetProducts():

- iterates over the pool and searches for installed Product resolvable
(uh, that could be improved by using byIdent iterators instead of iterating over the whole pool, but this is irrelevant here...)

(oh, I meant byKind iterator of course...)

Yes. As you may know the Product/Patch/Pattern is going to be changed. Currently these items are neither installed in the system nor available as installed items in the pool. 

It might be that 'being installed' becomes a property that applies to packages only, and for Product/Patch/Pattern we compute whether they are satisfied or broken.


I'll provide an interface in the pool that lets you access the installed-satisfies-however-computed products for this target.

*** Bug 367809 has been marked as a duplicate of this bug. ***

*** Bug 373367 has been marked as a duplicate of this bug. ***

*** Bug 375134 has been marked as a duplicate of this bug. ***

  ResPool pool( ResPool::instance() );
  for_( it, pool.satisfiedProductsBegin(), pool.satisfiedProductsEnd() )
  {
    Product_constPtr p( asKind<Product>(*it) );
    ...
  }

The above loop iterates over all satisfied products. Is satisfied status is computed and updated on each solver run. So it does not reflect any changes made since the last solver run.

I also adapted the loop in TargetProducts to iterate over satisfied products
(in SVN trunk).

Now someone has to take care that at the time TargetProducts is called, both - target and repositories - are loaded, and the solver was called.

Ladislav? Or is this to be done in YCP? If so, please reassign.

I think it should be rather fiex in the YCP level.

Pkg::TargetProducts() is used at two places in yast:

- in Products.ycp - that's a trivial fix to initial the target and the sources and run the solver (I'll fix that)

- in OSRPkg.ycp - it's tricky here because the repair module can be started from the installation media, I'm not sure whether the installation source is already registered when the module is started. Jiri?

(In reply to comment #10 from Ladislav Slezak)

> - in OSRPkg.ycp - it's tricky here because the repair module can be started
> from the installation media, I'm not sure whether the installation source is
> already registered when the module is started. Jiri?

I added the solver run, let's see if it works in beta1. 

I have adapted Product.ycp in yast2-2.16.51, resolving as FIXED.

Problem still present in yast2-2.16.52-6 (current factory).

Testcase:

echo '{import "Product"; y2milestone("Product is `%1`",Product::name);}' > ./ProductTest.ycp && /sbin/YaST2 ./ProductTest.ycp && grep "Product is" ~/.y2log


Logs "Product is ``" expected to log the product name.

YaST log: http://bw.uwcs.co.uk/ProductTest.log

Also, it now shows the distracting full screen package manager progress just for reading the product name, even without importing package callbacks, I expect that's another issue though.

I'll change the Product module to read /etc/SuSE-release file instead of using the package manager...

Call Target::release() for this:

      getZYpp()->initializeTarget( sysRoot );
      std::string release = getZYpp()->target()->release();

I fixed Product.ycp to read /etc/SuSE-release file directly because the module is imported in many yast modules which do not use package manager at all.

This will avoid initializing libzypp library just for reading a single file (when Martin's dlopen patch for is ready).

Fixed in yast2-2.16.55.

In current factory Product::name is reporting just "openSUSE". It should return "openSUSE 11.0" or "openSUSE Factory", including the version. Product::short_name should be the one with just the name.

    /**
     * General product name and version
     */
    global string name		= "";			// "SuSE Linux 8.1"
    global string short_name	= "";			// "SuSE Linux"
    global string version	= "";			// "8.1"
    global string vendor	= "";			// "SuSE Linux AG"

The method of identifying the product and version is really not something to break backwards compatibility on. 

Fixed in SVN.

Benji, thanks for looking at it.

*** Bug 381660 has been marked as a duplicate of this bug. ***

Submitted in yast2-2.16.61