Difference between pages "LXQt" and "Virtual Packages"

(Difference between pages)
(fix)
 
(Virtual packages, metapackages and package sets: when virtuals can be used)
 
Line 1: Line 1:
== About LXQt ==
+
Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.
  
LXQt is a lightweight Desktop environment. Some LXDE developers decided to create a Qt based version of their Desktop environment, it's name was lxde-qt. Around the same time some other people were working on a different minimal Qt based DE called razor-qt. When some developers of those projects met they decided to join forces and work together on one project. LXQt was born.
+
== Virtual packages, metapackages and package sets ==
 +
Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.
  
== Installation ==
+
Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.
  
It is recommended to set the LXQt mix-in before emerging it.
+
Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.
  
{{console|body=
+
Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.
###i## eselect profile add funtoo/1.0/linux-gnu/mix-ins/lxqt
+
###i## emerge lxqt-meta
+
}}
+
  
== Starting LXQt ==
+
Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.
  
You can either use a display manager to log into your system and start LXQt, or you can log in on a TTY and run {{c|startx}} to start xinit by hand.
+
== When virtual packages can be used? ==
 
+
For virtual package ebuild to work correctly, the two following requirements must be met:
=== xinit ===
+
# the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
 
+
# Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.
You should edit the file  {{c|~/.xinitrc}} if it already exists, and put {{c|"exec startlxqt"}} in there.
+
If it doesn't exist you can create it like this:
+
 
+
{{console|body=$##i## echo "exec startlxqt" > ~/.xinitrc}}
+
 
+
You might want to add the commands and options {{c|ck-launch-session dbus-launch --sh-syntax --exit-with-session}} to the {{c|exec]}} to start it with ConsoleKit and DBus.
+
In this case you also need to add ConsoleKit to the default runlevel:
+
 
+
{{console|body=
+
###i## rc-update add consolekit default
+
###i## rc
+
}}
+
 
+
 
+
 
+
=== Login Manager ===
+
 
+
Please take a look at http://www.funtoo.org/Package:XDM_%28Display_Manager%29 for this.
+

Revision as of 12:32, February 7, 2015

Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.

Virtual packages, metapackages and package sets

Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.

Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.

Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.

Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.

Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.

When virtual packages can be used?

For virtual package ebuild to work correctly, the two following requirements must be met:

  1. the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
  2. Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.