Talk:Libzypp/Application Layer

From openSUSE

--HuHa 09:54, 24 October 2007 (UTC) First draft complete. Starting discussion.

--User:Klaus_kaempf 12:00, 24 October 2007 (UTC)

Splitting it up into multiple pages ?!

The document is quite large and there are several independent areas touched.

How about splitting it into sub-pages so they can be edited/discussed separately ?

Selectables

Selectables should be multi-layer, e.g.

• type (package/patch/pattern/product)
• name
  • version1
    • repo1
    • repo2
    • system
  • version2
    • repo1
  • version3
    • system

--Duncan 12:39, 24 October 2007 (UTC) I don't think it is consistant. the tree you see here does not scale if you want to use other attributes, like vendor. Anyone has a solution on how to extend the groups without changing the simple model our UI developer need? Can you show how that multlayers scale adding another group like vendor? what do you put first, repo or vendor?, or version?

Notes

• type+name is a unique key to the selectable
• there are several versions (well, epoch-version-release to be precise) known
• for each version, there might be one or more repositories providing it
• for each version, there might be a special system repository, denoting an installed state
• there can be multiple versions installed in parallel

Questions

• how to detect that repo1 and repo2 really provide the identical version1
• more generic: How to identify identical packages ? (md5 sum ?, version compare ? version+vendor compare, version+dependency compare ?)

Selectable candidate

There is no such thing as a candidate resolvable within a selectable.

There can only be a "scheduled for installation" (resp. removal) at a specific layer (see above).

The following (use-)cases can exist

• User wants to install package foo
  • foo is scheduled for install (selected in ui-speak), but no specific version (resp. repo) is known
  • Its up to the dependency solver to choose the best version
• User wants a specific version of package foo
  • foo and a specific version is scheduled for installed, but no specific repo is known
  • Its up to the dependency solver to choose the best repo
• User wants a specific version from a specific repo of package foo
  • foo and a specific version of a specific repo is scheduled for installed
  • Dependency solver either can install this package or not (dependency conflict)

Only after the dependency solver has run, the to-be-installed version is known.

The repository is choosen at the commit step, after the user clicked Ok in the UI.

Selectable status

How about merging protected and taboo into a single semantic named locked ?

Here the same layering as in selectable candidate applies since the locking might be at

• the name (i.e. never install/remove a package named foo)
• the name + version (i.e. never install/remove the package foo at version 1.42)
• the name + version + release (this might be needed for certifications of enterprise products where even a maintenance update, while keeping the version, breaks certification)
• the name + repository (never install mplayer from opensuse, since it cannot play dvds ...)

API proposals anyone ?

How about adding (pages for) concrete API proposals for the various areas of the application layer ?

--HuHa 12:24, 24 October 2007 (UTC) My impression was we wanted to make libzypp easier to use. Now I see several proposals to redefine a lot of things that are well-defined and used all over the place. This is again making life more miserable for everybody, in particular for the UIs. Why?

--HuHa 12:30, 24 October 2007 (UTC) There is no such thing as a candidate resolvable within a selectable.

Yes, there is. For a user for sure there is. A user wants to know what version he will get when he installs something, not rely on guesswork. What is the UI supposed to display if there is no indication which version will be picked if the user chooses a package for installation?

It's a purely technical view to disregard the user's expectations here.

--Kmachalkova 13:51, 24 October 2007 (UTC) Installation Summary and Automatic Changes filter view are just different names for the same thing - filtering selectables according to their status. Only different subset of all possible status types is used in different cases So maybe this could be mentioned under common 'Filtering selectables by status' header?

And I also miss another important thing - filtering patches by category (this isNeeded, isSatisfied and @#^*&%^ magic)