Real introduction to Foresight Linux

[tforsman]

Foresight Linux is an OS for your computer/laptop. And here is some info about Foresight Linux:Rolling updatesRollback featureConary as package managerStandalone, not based on any other Linux dist.Easy to create own packages [2], maintain packagers and create a own repository address to use/share.32bit and 64bit always available. i686 system.i686 is a much more modern architecture. It includes practically every processor that’s Pentium II or better. x86_64 is a 64 bit extension to the x86 architecture. x86_64 processors can still run 32 bit operating systems (e.g. i386) if you so choose, but they’re also capable of running 64 bit operating systems.

the presentation that Michael Johnson gave at FOSDEM 2008 (follow along with his slides)Watch how fast a user in Foresight can update a package to newer version.That’s little info in generally. Let’s dig little deeper now.At anytime an update fails Conary will rollback to the previous job leaving your system dep complete and fully functional.How Conary Organizes PackagesIf you use debian or rpm repositories…you know that inside a repository directory “stable” (as an example) are all the stable packages for your distribution. The packages are versioned according to their upstream version (if the repository maintainers are sane) and maybe arch and revision number. This is done by hand. It is managed by hand. If developers/packagers cross names between repositories you are brought into dependency problems. To illustrate this concept, if you and I both packaged firefox3 and named it accordingly…and someone used both your and my repository…our versions would conflict because the packaging system wouldn’t know which one to install.Conary takes the manual operation from this…if you use a Conary based system, yourrepositories ARE VERSIONED. In other words, the repositories aren’t static directories that contain a bunch of packages…they are versioned branches that contain components of software.These components (packages) are also versioned according to upstream version…but revision is handled automatically by Conary…no manual process. This eliminates the possibility of having two packages named the same exact thing in different repositories. In other words, if Joe Schmoe is packaging Liferea for his apt.joeschmoe.com repository and names his package the same thing as say Joe Smith’s package for Liferea in his apt.joesmith.com repository we run into problems. With conary this NEVER WILL HAPPEN…EVER. This kills about 90% of dependency problems all together.But what about arch? Arch is architecture…32bit or 64bit…PPC and more. Once again, you’re bit by the possibility of conflicting names across repositories. You’re also limited in the name because a developer has to put the architecture INSIDE THE NAME. Take a look at liferea as an example: liferea-1.2.2-2.el5.rf.x86_64.rpm. Is this easy for an end user to understand? Is it the same as liferea-1.2.2-2.el5.rf.x86-64.rpm?Conary takes a different approach. Each package has a ‘flavor’ that it is ‘cooked’ (committed) in. There may be a 64bit flavor, 32bit flavor, Xen flavor, and so on. This flavor is visible to the user only if the user requests to see it…and it is NOT inside the name of the package. The package is still called, simply enough, liferea. Revision number, arch, upstream version, etc…are all handled automatically by Conary.You can see how creating and maintaining software would rely less on a manual process and more on automatic source controlled one with Conary. You can also see how organized Conary is with its packages. (this chapter comes from devnet)Conary treats packages as change-sets and not as a bundle of files. This means that when updating a package, Conary communicates with the repositories to determine what needs to change on the system to install the new package and only downloads the bits needed for that change. There are many advantages to this approach, but most visible to the user is the efficiency in bandwidth and speed.When updating a large package for the first time, you will essentially download the full package, however, when updating in the future the downloads could be significantly smaller. Here is an example: installing Abiword 2.2.6 on a system for the first time would be approximately a 15MB download, however updating to Abiword 2.2.7 is only 2.4MB.How can I be sure things still work if I remove a component from my system?First, Conary warns you if you are about to remove a component that is used to resolve a dependency elsewhere on the system. Conary keeps track of these dependencies for you. Second, you can use the –deps option to display dependency-related information. Furthermore, you can also use –file-deps to list component dependencies at the file level. Results display what the trove “requires” to resolve its own dependencies and “provides” to resolve other packages’ dependencies. You don’t have to track this information unless you really want to do so; trusting Conary’s warnings is usually enough to prevent mistakes when installing and removing software.What’s that colon for? Is “chromium:runtime” different than the “chromium” package?It is different, but part of the same package. When the package name is followed by a colon and another name,such as “chromium:runtime” and “chromium: doc,” this references a component.When the package is first built, Conary separates out the files into components.Each component represents some logical grouping of files within the package,such as everything needed to run the software or the documentation for how to use the software.This gives the flexibility for other packages to resolve dependencies by bringing in components rather than entire packages.It also gives users the freedom to uninstall components that are just taking up space without removing an entire package.But, enough about how awesome Conary can be.So unlike other packaging systems, where you might have 2 packages, firefox and firefox-devel, Conary would have one package with the devel headers split into firefox: devel. This is a great thing, you no longer end up installing -devel packages from random repos in your sources.list just because it looks like a newer version. The devel headers are just part of the same package, you just don’t have to have them installed. These components combined with rich dependancy information really shines.on debian or rpm based systems, when you do upgrade, then the packagemanager will pick the latest version from all packages. that is, if you upgraded yesterday, and i upgrade today then our systems may be different because i might have picked up a newer version of some package. in conary, all packages that are available for install are assembled into a group. this group is created by the distribution developer. when the group is built, it stores the version of each package. as a user packages are then installed from this group.just like packages, the groups have versions. when a package is updated, the group needs to be rebuilt (with a simple command) and when i update my desktop then the package manager first checks for a new version of the group, and then finds out which packages are updated within the group.to go back to the example, if you upgraded yesterday, and i upgrade today but i want a system identical to yours, i can ask you for the group version that you have and select that version explicitly.you can imagine how that simplifies testing. if a user has a problem, usually all we need to know is the version of the group. that alone will tell us every version of every single package that you have installed. or consider corporate deployment. the best practice for rpm and deb, as hinted in the article above, is to create a company internal repository where you can control exactly what versions are available, and then synchronize machines. with conary, all i need is the group version, or, the new system-model file. System-modelA 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. this ability is so significant that rpath, the company which develops conary even offers rhel and centos (and ubuntu server) repackaged in conary. (and apparently conary is now available for windows too)if you want to create a custom system for many machines, you can create your own group, inherit an existing group and make the necesary changes to it. a group can contain packages from multiple repositories,so there is no problem to mix and mach and still have full control over what is going on. this reduces the effort needed to create a derivative distribution by a huge amount. groups also help with automated rebuilds of the source. if a library is updated, then all packages that depend on that library can be rebuilt automatically with a single command.recipes for packages are astonishingly short. in most cases it only takes specifying of an url and some dependencies in order to build a package.conary also remembers if i remove packages, even files, so when a group or a package is updated, then such removed files are not reinstalled.The system model mode is intended to become the normal update mode for Conary-based systems in the future. It works by creating a set of troves that define the system, and then moving the system to that definition. It is conceptually similar to building a group into a repository and then migrating to that group. Significant differences include:In a group, all trove references are absolute, but in a model,you can choose whether references are absolute. Migrating to a specific version of a group will always move the system to the exact set of packages referenced, but re-applying a system model will update troves that are not pinned down to a specific version. There is no group name for the set of troves.There is no version for the set of troves. (The version operation in a system model does not provide conary versioning.) Path and version conflicts are not checked when assembling the set of troves. (No group policy is run at all.) This means that path and version conflicts will be found only while installing the packages.A system model that installs only a single group will function similar to migrate mode. The most obvious difference is that migrate mode honors variations in byDefault settings in the system database(that is, an optional component of the trove(s) migrated to that has been installed on the system will still be installed after the migrate operation finishes), whereas a system model update honors those changes only if they are represented in the model itself.Info about some packagesThere is few applications that makes a user happy with a Linux dist, so here is a few that works perfectly with Foresight:Chromium: Updates almost every week. Flash, embedded trailers works out of the box.Nvidia/ATI: Easy to install, but legazy drivers is little harder. But works to get them in too.Wine: When installed, everything works as it should with wine. 32bit and 64bit works fine from start.Create own packagesMaybe sounds hard, but think again. It’s very easy.1: Setup environment2: Full packaging exampleAnd as you saw in the video earlier in this post, an update of a package can go really fast What do you really get from creating own packages?First of all, very easy to maintain and update. Usually updating before every linux dist out there. Very easy to uninstall a package. Very easy to switch from stable repo of a package to unstable and back again. Easy to change parameters for a package and repack it for your needs. Like remove uneeded dependencies, as you might don't want to get plugins for that application, or similar...And as soon you see a new application, like radiotray, you can easily make a package and test it. As soon you are done testing, unistall it as it never was installed. Or even better, let Foresight users also use it and suggest it to be added in Foresight repo. (can offcourse be installed from your personal repo too)Version 2.5.1 (2011.07.15)Gnome 32 bit: http://www.rpath.org/downloadImage?fileId=43360Gnome 64 bit: http://www.rpath.org/downloadImage?fileId=43357To get started with Foresight Linux:Give root a password, open terminal and write: sudo passwd rootthen write password 2 times.Look at foresight userguide at system > Foresight userguideTo get common codecs, open terminal and write: sudo conary update group-codecs (not needed anymore)To install Nvidia drivers: sudo conary update nvidia nvidia-kernelsudo nvidia-xconfigTo install ATI drivers: sudo conary update ati-fglrx ati-fglrx-kernelsudo aticonfig --initial --input=/etc/X11/xorg.confSearch after applications or browse after applications: rBuilder onlineSome known problems:Packagekit, the gui for conary isnt working as it should.This is also holding up the new release of a new iso for stable repo.First time when trying to update system can fail, a restart of system will fix it. Edited October 25, 2011 by tforsman