Difference between pages "Virtual Packages" and "Package:XDM (Display Manager)"

(Difference between pages)
(Common uses for virtual packages: libraries)
 
m
 
Line 1: Line 1:
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.
+
{{Ebuild
 +
|Summary=X.Org xdm application
 +
|CatPkg=x11-apps/xdm
 +
|Maintainer=
 +
|Homepage=http://www.freedesktop.org/wiki/display_manager/
 +
}}
  
== Virtual packages, metapackages and package sets ==
+
XDM ([[Wikipedia:XDM_(display_manager)|Wikipedia page]],) also known as the X Display Manager, is an application that typically starts at system startup, and presents a graphical login screen. Once a user successfully logs in, their X session begins.
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.
+
On Gentoo systems, XDM installs the {{f|/etc/init.d/xdm}} init script, which via the {{f|/etc/conf.d/xdm}} configuration file is used to start other display managers, such as GNOME's {{c|gdm}}.
  
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.
+
==install==
 +
{{note|make sure your x11 is working properly before attempting to use xdm}}
 +
{{console|body=###i## emerge xdm}}
  
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.
+
==configure==
 +
xdm is controlled by {{f|/etc/conf.d/xdm}}.
  
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.
+
xdm is often paired with other, more modern display managers.
 +
see:
 +
*{{package|x11-misc/lightdm}}
 +
*{{package|gnome-base/gdm}}
 +
*{{package|kde-base/kdm}}
 +
*{{package|x11-misc/slim}}
  
== When virtual packages can be used? ==
+
==init==
For virtual package ebuild to work correctly, the two following requirements must be met:
+
{{console|body=###i## rc-update add xdm
# 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.
+
###i## rc}}
# 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.
+
{{EbuildFooter}}
 
+
Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.
+
 
+
== Common uses for virtual packages ==
+
=== System components and services ===
+
Example: ''virtual/service-manager''
+
 
+
One of the common uses for virtuals is to define abstract ''system services''. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.
+
 
+
The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.
+
 
+
=== Tools provided by multiple packages ===
+
Example: ''virtual/eject''
+
 
+
This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).
+
 
+
While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.
+
 
+
=== Libraries with certain degree of ABI compatibility ===
+
Example: ''virtual/libudev''
+
 
+
This kind of virtuals is to allow switching between multiple providers of a library. However, virtual can only be used when the various providers provide ABI-compatible variants of the same library.
+
 
+
Virtual ebuild should have a separate version at least for every ABI version of the library. The ebuilds should have appropriate subslots and depend on respective subslots or versions of the provider that provide the library with necessary ABI. For example, virtual/libfoo-1 depends on specific versions of libfoo providers that provide libfoo.so.1, while virtual/libfoo-2 depends on versions providing libfoo.so.2. This guarantees that the reverse dependencies of the virtual will be rebuilt when the underlying library is upgraded.
+

Latest revision as of 13:41, February 8, 2015

x11-apps/xdm


Source Repository:Gentoo Portage Tree
Homepage

Summary: X.Org xdm application

Use Flags

consolekit
Enable native sys-auth/consolekit support
xdm-auth
Enable XDM-AUTHENTICATION-1 support

News

Drobbins

Pre-built kernels!

Funtoo stage3's are now starting to offer pre-built kernels for ease of install. read more....
12 May 2015 by Drobbins
Drobbins

Better Experiences: Ego and Vim

Info on Funtoo's new personality tool called 'ego', and user-focused updates to vim's defaults.
27 April 2015 by Drobbins
Drobbins

How We're Keeping You At the Center of the Funtoo Universe

Read about recent developments that keep you, our users, at the forefront of our focus as Funtoo moves forward.
10 April 2015 by Drobbins
View More News...

XDM (Display Manager)

Tip

This is a wiki page. To edit it, Create a Funtoo account. Then log in and then click here to edit this page. See our editing guidelines to becoming a wiki-editing pro.


XDM (Wikipedia page,) also known as the X Display Manager, is an application that typically starts at system startup, and presents a graphical login screen. Once a user successfully logs in, their X session begins.

On Gentoo systems, XDM installs the /etc/init.d/xdm init script, which via the /etc/conf.d/xdm configuration file is used to start other display managers, such as GNOME's gdm.

install

Note

make sure your x11 is working properly before attempting to use xdm

# emerge xdm


configure

xdm is controlled by /etc/conf.d/xdm.

xdm is often paired with other, more modern display managers. see:

init

# rc-update add xdm
# rc