The latest groups on fl:2-devel contain a snapshot of the conary-2.2
branch. This is the branch of conary that contains the "system model"
code that you may have heard mentions of on #foresight-devel
First: This new version of Conary will not automatically switch to
"system model" update mode. Unless you choose to switch to "system
model" mode, your update experience should not change except that
you will currently see that the version of conary that you have
installed as a very long version number. The "updateall" and
"migrate" models for update should continue unchanged. Warning to
those prone to "tl;dr" -- this email is long; if it's too long,
please search for "So now" if you want to know how "system model"
updates work for your system. (But you'll be missing good stuff
if you do!)
Second: This new version of Conary should not require updates to
rMake or rBuild; it is expected to be compatible. If you have any
new difficulties with rMake or rBuild, please let me know.
There are a few new features in this release. Here is a selection
from the current summary of what will go into the NEWS file when
a release is made:
o New Features:
* The "cvc explain" command now honors the PAGER environment
variable, and if PAGER is unset or is set to "less", has
additional formatting that shows more character styles.
* GroupSetRecipe, a new superclass for building groups, has been
added. Documentation is available via "cvc explain"; start with
the command "cvc explain GroupSetRecipe" and follow references to
Repository, TroveSet, and SearchPath documentation.
* A new update mechanism called "system model" is added. In this
model, a file called /etc/conary/system-model describes what
should be installed on the system. This file is modified by
certain conary update commands, and can also be edited with a text
editor. The system model allows a system to be updated relative
to a search path that includes groups as well as labels, leading
to more coherent sets of updated packages. It also allows re-
starting updates with transient failures; the filename /etc/conary
/system-model.next is reserved for storing the system target state
during an update operation.
* The "conary install" command has been added. It is equivalent to
the "conary update --keep-existing" command. While the "--keep-
existing" argument option has been not commonly recommended in the
old update model because it can easily introduce packages with
versions that are unintentionally out of sync, it is commonly
useful with a system model because the search path used for a
system model can keep versions in sync.
* The new group policy PathConflicts has been added, allowing more
granular control over which paths are allowed to conflict.
(CNY-3505)
* Added support for specifying trove requirements on other troves.
(CNY-3517)
First, a plug for a small but I hope significant usability change:
developers should try out "cvc explain" and look at the improved
formatting; the developer information should be easier to read now.
The two real big new features in this release are GroupSetRecipe and
"system model" updates. GroupSetRecipe is a new way of writing group
recipes that is significantly different from old group recipes. Many
groups are easier to construct with GroupSetRecipe. Foresight groups
will be moving from GroupRecipe to GroupSetRecipe at some point. We
expect further change in GroupSetRecipe in the near future.
So now, the part of this email that you really wanted to read -- an
introduction to "system model" updates.
The "updateall" model does not (cannot) distinguish between a
package that is on the system because it was explicitly added
and a package that is on the system because it was dragged in to
satisfy dependencies. Furthermore, when it resolves dependencies,
it resolves them against the installLabelPath -- there is no way
for it to resolve them only against a certain version of the main
container group. This can lead to version/path conflicts, with
which many experienced foresight are familiar. For this reasons,
some people (like me!) started managing their Foresight systems
by defining groups that defined exactly what should be installed
on the system, and then used "conary migrate group-mydesktop"
to keep the systems up to date.
Having to build a group to successfully manage a single desktop
system seems like unnecessary overhead. It is too big a hurdle.
It is absolutely not something that you want to make an end user
to. It's great that you *can* do this -- I still use this for
cases where I want to keep a whole set of desktop systems that
I am managing and want to keep in sync and under control -- but
it's less good to *have* to do this for legitimately normal
circumstances.
The question is then: How can we get the most important benefits of
"migrate" mode without requiring people to build groups? Clearly to
answer that, we need to list some of those benefits:
* Stable updates -- when building groups, you can have groups in a
search path, so that you can add just one package, plus its
dependencies, without changing the version of the base OS, and
without introducing path/version conflicts.
* Explicit separation of packages that are intended to be installed,
with troves included only for dependency completeness dropped when
they are no longer required.
Conceptually, you would like something vaguely like what you might
mean by "conary migrate group-gnome-dist-devel=version +httpd
+mod_ssl -vmstat +mypackage=mylabel/myversion" (if that were a
legal command line...) but you don't want to have to maintain all
that text on the command line, you want it stored in a file.
Enter the file /etc/conary/system-model
This file specifies the search path (which, like a group search
path, can include both references to troves, including specific
versions of troves, as well as to labels) and the list of package
install/update/erase operations that should be taken relative to that
search path. All system update operations then happen by modifying
that specification, building something like a light-weight group (we
call it a "trove set"; it's the building block in GroupSetRecipe),
and then migrating the system to comply with that specification.
When you run conary install/update/erase commands, they modify that
file, and then apply it to the system.
When you run the "conary updateall" command, it updates the versions of
troves in the search path to the latest versions, then applies that
modified system model to your system.
You can use vi to edit this file, and then run the "conary sync"
command to apply the system model to your system.
Every time you apply the system model to your system, if conary has
changed the model, it saves the change as /etc/conary/system-model.next
and tries the update. If the update fails due to a real problem (such
as a path conflict) you can revert the update with a rollback. If
the update fails due to a transient error (your cat ate the network
cable, your dog unplugged the wireless access point), you can run
the "conary sync" command to pick up where you left off -- it will
apply the contents of the /etc/conary/system-model.next file. (Note
that if your model has bits asking for the very latest version of
a package, picking up where you left off may change the result
slightly; if you don't want that, you can add more packages to your
search path to pin down the versions and make these updates more
stable.)
One more piece of good news: Conary caches a bunch of the information
required to calculate the update locally, so you no longer need to
download a large changeset to determine that there's nothing to do.
Part of implementing system model updates was making it possible to
download less information to make the decision (new repository APIs
were required for this), and then caching that smaller amount of
data makes sense. This means that you need to download far less
data to determine that "no updates are available".
What does a system model look like? Here's a simple example:
search group-world=foresight.rpath....@fl:2-devel/2.4.9.1+2010.10.12-0.2-2
install group-gnome-dist-devel
install openbox
install chromium
install wireshark tshark
You can construct one by hand, if you like, by looking at the output
of the "conary updateall --items" to show you things you added that
are not part of groups. However, that won't show you things that are
in the groups but not installed by default. So a better way is to try
out the script that generates a model that represents the state of
your system. It is heuristic and can never be perfect, so expect to
have to edit the output with your favorite text editor, but it is
a good start. As a non-root user, run:
/usr/share/conary/genmodel
This will take a while to run! It is building sample models and
comparing them to your system, iteratively. When it has done as
much as it knows how to do, it will show you what it has done, and
then offer to do two things: 1) write the model to disk, and 2)
email debugging output to rPath. Whether or not you write the
model to disk, please do email the debugging output to rPath.
(If you do not have local mail set up, you should be able to use
"mx2.rpath.com" when it asks you for the mailhost, since that will
accept mail being sent to rpath.com.)
If you run the script as root *AND* you choose to write the model
to disk, it will write it to /etc/conary/system-model. If this
file exists, the conary command line only accepts update commands
that work with the system model, and will give you errors otherwise.
(You can rename it out of the way if you want to revert to updateall
model.)
When using system model update mode, you might find one behavior a
bit confusing at first. One of the major points of system model is
that it allows you to keep a system synchronized with groups; you
have a real search path. This is great -- except for those few
times that you really, really don't want it. Imagine the model:
search group-world=foresight.rpath....@fl:2-devel/2.4.9.1+2010.10.12-0.2-2
install group-gnome-dist
This has conary=2.2.alpha_9c0ae70f5fde-1-1 in it. Imagine that you
want to test conary=2.2.alpha_d8cd5cea61d1-1-1 before new groups are
built. So you run:
$ sudo conary update conary=foresight.rpath....@fl:2-devel
You are thinking that you'll get the latest version of conary from
that label. But you're wrong. Your search path includes the conary
that is already installed on your system, so your command won't actually
change your system. Instead, you'll have to do:
$ sudo conary update
conary=foresight.rpath....@fl:2-devel/2.2.alpha_d8cd5cea61d1-1-1
As a developer, you'll find that from time to time, you'll really want
to edit your /etc/conary/system-model file with a text editor to make
it represent what you really want on your system, rather than just being
a collection of results of conary commands you have run.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
