Feature changed by: Michal Vyskocil
Feature #305590, revision 3
Title: Virtual packages and virtual joint projects
Buildservice: New
Priority
Requester: Desirable
Requested by: Stanislav Brabec (sbrabec)
+ Interested: Michal Vyskocil (mvyskocil)
Interested: Pavol Rusnak (prusnak)
Partner organization: openSUSE.org
Description:
http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00094.html
Virtual packages and virtual joint project would be a special type of
projects, that are part of a standard binary repository, but they have
no source present in the project.
It may have several typical use cases:
Virtual dependency packages ---------------------------
When a project intents to update a library to a newer version, virtual
dependency packages and projects may determine packages that will have
broken/changed dependencies after installing of a new library.
How it should look.
Either package or a project should have a new attribute:
"Rebuild parent project packages"
Possible values:
"ignore": Rebuild only packages in this project and nothing else (just
the current behavior)
"rebuild broken": Rebuild parent project packages, that cannot be used
with newer version any more (it typically happens for package, that
require exact version it is built against, or packages that don't
follow shared library packaging conventions)
"smart rebuild": Rebuild packages that require package or symbol that
are no more part of the output of the new package.
"all dependencies": Behave just like a single repository and rebuild
everything which uses the new in the build.
Examples of use for particular values:
"rebuild broken": Building some modules require the same version of the
base package it was build with. When trying to update base package in a
project, it will rebuild all such modules.
"smart rebuild": Testing package poppler update: New poppler has a new
soname and it requires to rebuild all packages that are linked with
poppler. However it is possible to install these packages (and use
shared library from the parent project), testing of the new library
requires to rebuild these package with the new library).
"all dependencies": Testing new core package (bison, gcc). All
packages, that have this package in BuildRequires on build system will
be rebuilt.
Virtual package may become non-virtual. If you need to patch one of the
packages to be able to rebuild it in the new repository, you have to
link it physically to the joint repository. In this moment, package
becomes equal to the normal link package, disabled by default.
Virtual/non-virtual joint project ---------------------------------
Just now, one can include two different projects, that have a
disjunctive packages.
Virtual joint project would determine packages that will build
differently (or break) in one or another parent repository and rebuild
them as a separate repository.
Virtual joint project could be a separate project that contains
rebuilds of packages in the intersection of both project.
Virtual joint project may become non-virtual. If you need to patch one
of the packages to be able to rebuild it with both projects included,
you have to add it physically to the joint repository. In this moment,
the joint project feature would be equal to the normal repository with
"Rebuild parent project packages" set.
Example:
Suppose you have a testing repository of new poppler (different soname)
and a multimedia:photo with a new version of GIMP (requires poppler).
You can easily include both multimedia:photo and poppler test
repositories, but you cannot test new gimp with a new poppler.
Creating of virtual joint project will automatically detect these
packages and rebuild them.
There could be again the tag "Rebuild parent projects packages" with
the same values as above.
Benefits:
Virtual packages: Now they are often substituted by links. Several
years later, nobody knows, why such link was created and the link may
rot there forever.
Virtual joint project: It will allow to test result of a dangerous
package check-in without actually doing it.
--
openSUSE Feature:
https://features.opensuse.org/?rm=feature_show&id=305590