Feature added by: Pavol Rusnak <prusnak(a)novell.com>
Feature #305590, revision 1, last change by
Title: Virtual packages and virtual joint projects
Requested by: Pavol Rusnak <prusnak(a)novell.com>
Partner organization: openSUSE.org
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"
"ignore": Rebuild only packages in this project and nothing else (just the
"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
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.
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
There could be again the tag "Rebuild parent projects packages" with the same
values as above.
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.