Mailinglist Archive: zypp-devel (115 mails)
| < Previous | Next > |
[zypp-devel] Re: [yast-devel] [RFC] QueryBuilder and (Resolvable)Query
- From: Michael Andres <ma@xxxxxxx>
- Date: Tue, 3 Jul 2007 11:58:50 +0200
- Message-id: <20070703095849.GA23060@xxxxxxx>
On Tue, Jul 03, Katarina Machalkova wrote:
> Hola!
>
> > A 'Selectable(Package,glibc)' will contain at most ONE installed,
> > and all available glibc packages. ;(
> >
> > There is no difference, unless more than one version of a package
> > is installed. In that case there are as many Selectables as there
> > are versions installed. Each Selectable links to only ONE installed
> > but to ALL available versions.
> >
> > Unfortunately we support this (e.g. multiple kernel versions being
> > installed at the same time).
>
> My apologies for the dumb question *), but if the concept of selectables has
> so many drawbacks, why did we decided to use it? Why didn't we switch to
> PoolItems instead? Can anyone (Michael, HuHa,...) comment on that in some
> human-readable, easy-to-understand way?
Historical. You may remember the first libzypp was a bit late, so there
was little time to migrate the UI from using the old y2pm to zypp.
In the old y2pm the status information was kept in a 'Selectable'. This
was possible, because the old y2pm neither supported multiple installed
nor multiple available versions. There was at most one installed and one
available item and the status.
Now we may have multiple installed and multiple available versions. And
each item has it's individual status.
We tried to find some 'Selectable' that allowed to reuse as much of the
existing UI code as possible. An Item that mangles the individual stati
into one UI-status. And we found one, but it has some drawbacks.
The concept of a "Selectable" is right. An easy view and access to the
pool. Pkg-bindings and zypper would like to use something like this as
well.
Changing (fixing) the ui::Selectable will lead to changes at the UI.
But it would allow us to bring PoolItems and Selectables closer together.
Or we had to invent something in parallel to the ui::Selectable for
Pkg-bindings and zypper.
--
cu,
Michael Andres
+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres YaST Development ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
> Hola!
>
> > A 'Selectable(Package,glibc)' will contain at most ONE installed,
> > and all available glibc packages. ;(
> >
> > There is no difference, unless more than one version of a package
> > is installed. In that case there are as many Selectables as there
> > are versions installed. Each Selectable links to only ONE installed
> > but to ALL available versions.
> >
> > Unfortunately we support this (e.g. multiple kernel versions being
> > installed at the same time).
>
> My apologies for the dumb question *), but if the concept of selectables has
> so many drawbacks, why did we decided to use it? Why didn't we switch to
> PoolItems instead? Can anyone (Michael, HuHa,...) comment on that in some
> human-readable, easy-to-understand way?
Historical. You may remember the first libzypp was a bit late, so there
was little time to migrate the UI from using the old y2pm to zypp.
In the old y2pm the status information was kept in a 'Selectable'. This
was possible, because the old y2pm neither supported multiple installed
nor multiple available versions. There was at most one installed and one
available item and the status.
Now we may have multiple installed and multiple available versions. And
each item has it's individual status.
We tried to find some 'Selectable' that allowed to reuse as much of the
existing UI code as possible. An Item that mangles the individual stati
into one UI-status. And we found one, but it has some drawbacks.
The concept of a "Selectable" is right. An easy view and access to the
pool. Pkg-bindings and zypper would like to use something like this as
well.
Changing (fixing) the ui::Selectable will lead to changes at the UI.
But it would allow us to bring PoolItems and Selectables closer together.
Or we had to invent something in parallel to the ui::Selectable for
Pkg-bindings and zypper.
--
cu,
Michael Andres
+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres YaST Development ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |