Posted by: Anonymous Coward
on November 11, 2005 05:26 PM
A snip from the Conary web site
"Anyone responsible for system maintenance or system configuration wants to accomplish their tasks in the simplest and safest manner. Traditional packaging systems make loading a new release of an application or library easy, but do so in a "blanket" manner. When traditional systems update packages, they have no regard for determining whether the files being replaced are pristine or not. Changes are simply overwritten whether the file has been changed or not. Writing unchanged files over again creates greater overhead and is intrusive to a well-running system. The risk is normally small, but the overhead is significant.
Just as source code control systems use patch files to describe the differences between two versions of a file, Conary uses changesets to describe the differences between versions of components. These changesets include the actual changes in contents in existing files, the contents of new files, name changes (if files are renamed but otherwise unchanged, only the change in name is included), permissions changes, and so forth. They also can include changes to components as well as to individual files.
Conary changesets are quite often transient objects; they are created as part of an operation (such as fetching a new version from a repository) and disappear when that operation has completed. They can be stored in files, however, which allows them to be distributed like the package files produced by a classical package management system. Applying changesets rather than installing whole new versions of libraries and applications allows Conary to update only the parts of the system which have changed, rather than blindly reinstalling every file. Changesets are more efficient than classic packages in at least two ways: they take less space to express what changes to make on the system, and they take less time to apply the changes to the system when the set of changes required is small. These benefits apply whether the changesets are acquired through a network connection to a repository, on a CD, or via any other method.
Representing updates as changesets not only saves space and bandwidth, it also allows merging. Conary intelligently merges changes to file contents and file metadata such as permissions. This capability is very useful if you wish to maintain a branch of an application or library while keeping current with vendor maintenance, while adding a couple of patches to meet local needs.
Conary also preserves local changes in essentially the same way. When, for example, you add a few lines to a configuration file on an installed system, and then a new version of an application is released with changes to that configuration file, Conary can merge the two unless there is a direct conflict (unusual, but possible). If there is a conflict, it is marked as such so that modifications can be applied. Also, if you change something as simple as a file's permissions, those changes will be preserved across upgrades.
A local changeset is a special changeset that represents the changes made on a local system. There are two ways Conary allows you to commit local changesets: committing a local changeset to a repository, and distributing the changeset to individual systems. The first is better for systems with entirely centralized management policies, and the latter for individual systems that are expected to autonomously update themselves asynchronously.
Changesets represent a sane approach to preserving changes to a system while ensuring system integrity and limiting resources used to make such changes. System customization and maintenance are no longer an obstacle with Conary."
Learn about Linux
Download Linux
Get Linux help
Re:Some Clarifications
Posted by: Anonymous Coward on November 11, 2005 05:26 PM"Anyone responsible for system maintenance or system configuration wants to accomplish their tasks in the simplest and safest manner. Traditional packaging systems make loading a new release of an application or library easy, but do so in a "blanket" manner. When traditional systems update packages, they have no regard for determining whether the files being replaced are pristine or not. Changes are simply overwritten whether the file has been changed or not. Writing unchanged files over again creates greater overhead and is intrusive to a well-running system. The risk is normally small, but the overhead is significant.
Just as source code control systems use patch files to describe the differences between two versions of a file, Conary uses changesets to describe the differences between versions of components. These changesets include the actual changes in contents in existing files, the contents of new files, name changes (if files are renamed but otherwise unchanged, only the change in name is included), permissions changes, and so forth. They also can include changes to components as well as to individual files.
Conary changesets are quite often transient objects; they are created as part of an operation (such as fetching a new version from a repository) and disappear when that operation has completed. They can be stored in files, however, which allows them to be distributed like the package files produced by a classical package management system. Applying changesets rather than installing whole new versions of libraries and applications allows Conary to update only the parts of the system which have changed, rather than blindly reinstalling every file. Changesets are more efficient than classic packages in at least two ways: they take less space to express what changes to make on the system, and they take less time to apply the changes to the system when the set of changes required is small. These benefits apply whether the changesets are acquired through a network connection to a repository, on a CD, or via any other method.
Representing updates as changesets not only saves space and bandwidth, it also allows merging. Conary intelligently merges changes to file contents and file metadata such as permissions. This capability is very useful if you wish to maintain a branch of an application or library while keeping current with vendor maintenance, while adding a couple of patches to meet local needs.
Conary also preserves local changes in essentially the same way. When, for example, you add a few lines to a configuration file on an installed system, and then a new version of an application is released with changes to that configuration file, Conary can merge the two unless there is a direct conflict (unusual, but possible). If there is a conflict, it is marked as such so that modifications can be applied. Also, if you change something as simple as a file's permissions, those changes will be preserved across upgrades.
A local changeset is a special changeset that represents the changes made on a local system. There are two ways Conary allows you to commit local changesets: committing a local changeset to a repository, and distributing the changeset to individual systems. The first is better for systems with entirely centralized management policies, and the latter for individual systems that are expected to autonomously update themselves asynchronously.
Changesets represent a sane approach to preserving changes to a system while ensuring system integrity and limiting resources used to make such changes. System customization and maintenance are no longer an obstacle with Conary."
#