Home_greyopenFATE - openSUSE feature tracking > #305590
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Virtual packages and virtual joint projects

Feature state

Buildservice
Duplicate of #307915

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.

Relations

  • Duplicate of feature #307915:

Discussion


icons/user_comment.png A. S. wrote: (8 years ago)

Large parts of this request will be possible via the project source links in 2.0. Let's implement this first and open dedicated requests in case you still miss stuff afterwards.

Last change: 8 years ago
Voting
Score: 0
  • Negative: 0
  • Neutral: 0
  • Positive: 0
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint