On Thu, Jan 30, 2014 at 02:30:47AM +0100, Martin Bähr wrote:
> can you explain what GroupSetRecipe is doing differently?
It's system model for groups... Or, rather, system model is
GroupSetRecipe for system management. Well, it's a little bit
of both.
It is more pythonic groups, in that "explicit is better than
implicit".
Basically, the original GroupRecipe tried really hard to Do The
Right Thing, not exposing much of the logic. It was intended to
be a declaration of what you wanted done, and then it would go
do it. There were two problems. The big problem was that when
it turned out that it did something you didn't expect, it was
hard to understand why; hard even to decide whether it was a bug
or a feature. The second was that to try to figure out what you
meant was very expensive, computationally speaking. So we end
up with 1-2 hour group cooks for Foresight. That was not what
we were trying for!
Fairly early on, we had the idea that we wanted to be able to use
set operations to define groups. Even before rPL2, I think, we
had sketched out ideas of what that might look like, but we were
not satisfied. It took a few years before we figured out a way
to expose set arithmetic in a way that would express the things
that one would want to do in a group and was still declarative,
and would have much better performance.
GroupSetRecipe and system model share a lot of implementation.
They call the same underlying actions. You can think of system
model as a set of operations to define a single anonymous group
that is "the stuff on this system". GroupSetRecipe lets you
define many such sets. One of the ways to create one of those
sets in GroupSetRecipe is by using the language of system model,
the Conary Model Language (CML). That's so that you can easily
create a group from a system model that you have defined on a
development system. But you can also use set operations. Use
cvc explain GroupSetRecipe
to read documentation on those operations and see examples.
So to create groups with GroupSetRecipe, you directly operate
on sets of troves and compose them into groups.
It also has some nice debugging features, like being able to
print pretty verbosely what it is doing (dumpAll and track),
and being able to output a dot graph showing how the operations
in the recipe are linked together (writeDotGraph).
> is that a new feature that fl:2 could be switched to if we were still
> developing it or are there other reasons for not using it in fl:2?
António said that he tried but didn't quite get exactly the same
groups out and didn't want to break anyone's systems. It was only
a question of available time to implement and evaluate because the
Foresight groups are so big and complex; it's not that it couldn't be
implemented, since it would be possible to create all the literal
sets that are in the existing Foresight groups; it was that he
didn't find a way to express those sets that would be maintainable.
But when the goal is changing to a new major version, differences
don't get in the way, and starting with GroupSetRecipe will be so
much easier.
> wouldn't it be the other way around? if i have a package that doesn't
> specifically only work with f:20 i put it on fl:3
You are saying that the packages is intended to work in the fl:3
context, which is intended to be a rolling context that moves from
f:20 to f:21 to f:22, etc.
So you're saying the same thing I am.
It's expressing your intent with regard to the usage context.
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
