Mailinglist Archive: opensuse-buildservice (295 mails)

< Previous Next >
[opensuse-buildservice] [RFC] General use of enable/disable flags.
  • From: Marcus Rueckert <mrueckert@xxxxxxx>
  • Date: Wed, 14 Mar 2007 18:57:40 +0100
  • Message-id: <20070314175739.GA16336@xxxxxxx>
General use of enable/disable flags
=====================================

1. Current state
==================

Currently the enable/disable tags only influence the build handling.
XML wise they are direct children of the <package> element.

The schema for enable/disable tags currently is:

[[[
<xs:simpleType name="buildarchitectures">
<xs:restriction base="xs:string">
<xs:enumeration value="i586"/>
<xs:enumeration value="x86_64"/>
</xs:restriction>
</xs:simpleType>

<xs:complexcontent name="toggle"> <!-- tbd: type name -->
<xs:attribute name="arch" type="buildarchitectures" use="optional" />
<xs:attribute name="repository" type="xs:string" use="optional" />
</xs:complexcontent>
<xs:complexType name="package">
<xs:sequence>
...
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="enable" type="toggle" />
<xs:element name="disable" type="toggle" />
</xs:choice>
</xs:sequence>
...
</xs:complexType>
]]]

A sample:
[[[
<package name="retty" project="home:darix">
<title>Attach processes running on other terminals</title>
<description>...</description>
<disable arch="x86_64"/>
</package>
]]]

This works fine as long you only want to have one field to
enable/disable.

2. Planned changes
====================

There are more flags, which should be configurable by the user:

* build
Will this package be build?
* publish
Will the package synced out?
* debuginfo
Will the buildservice automatically generate debuginfo package?
* usedforbuild
Will the package be used for building other package in the same
project?
* more?

The xml format has to be altered in a non backward compatible way. The
enable/disable tags as direct children of <package> are removed and new
children for each block is added. Furthermore we add the same tags to
the project tag. That gives us the same configurability as at the
package level.

The resulting xml schema:

[[[
<xs:simpleType name="buildarchitectures">
<xs:restriction base="xs:string">
<xs:enumeration value="i586"/>
<xs:enumeration value="x86_64"/>
</xs:restriction>
</xs:simpleType>

<xs:complexcontent name="toggle"> <!-- tbd: type name -->
<xs:attribute name="arch" type="buildarchitectures" use="optional" />
<xs:attribute name="repository" type="xs:string" use="optional" />
</xs:complexcontent>

<xs:complexType name="complextoggle"> <!-- tbd: type name -->
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="enable" type="toggle" />
<xs:element name="disable" type="toggle" />
</xs:choice>
</xs:complexType>

<xs:group name="toggleGroup">
<xs:sequence>
<xs:element name="build" type="complextoggle" minOccurs="0" />
<xs:element name="publish" type="complextoggle" minOccurs="0" />
<xs:element name="debuginfo" type="complextoggle" minOccurs="0" />
<xs:element name="usedforbuild" type="complextoggle" minOccurs="0" />
<xs:sequence>
</xs:group>

<xs:complexType name="package">
<xs:sequence>
...
<xs:group ref="toggleGroup" />
</xs:sequence>
...
</xs:complexType>

<xs:complexType name="project">
<xs:sequence>
...
<xs:group ref="toggleGroup" />
</xs:sequence>
...
</xs:complexType>
]]]


3 The logic
=============

All 4 items have a similar complexity at the configuration level. It
felt quite natural to resuse the existing code for enable/disable for
all of them.

When testing if a feature is disabled or enabled the build service
first checks if there is a matching enabled element. If one is found,
the feature is enabed. Otherwise it checks of a matching disabled
element. If one is found, the feature is disabled, otherwise the
default applies. The order of the disable/enable elements is not
relevant for the result. As the build service first checks enable and
then disable, you can re-enable a specific architecture or repository
which is disabled by a broader element, but not vice versa.

The new tags might have different defaults. Furthermore combinations
of different tags have implied logic.


3.1 "build"
-------------

The default remains enabled.


3.2 "publish"
---------------

The default remains enabled.


3.3. Interaction between "build" and "publish"
------------------------------------------------


3.3.a build and publish enabled
---------------------------------

Package gets build and synced to the outside


3.3.b build enabled and publish disabled
------------------------------------------

Package gets built and but only synced into the internal repository.
You still can download the binaries from package status page via the
webinterface/api host. The old packages will be preserved

Use case:
This is a nice way for e.g. KDE:KDE3 to prepare a new kde3 release.

3.3.c build disabled and publish enabled
-----------------------------------------

If publishing of a package is enabled and you disable a package,
the old packages will be purged in the public repository.
The other option is to add a purge command to the api and let
the user purge the rpms manually.

Use case:
This way you can remove broken packages from the repository.


3.3.d build disabled and publish disabled
------------------------------------------

If publishing of a package is disabled when you disable building of a
package, the old packages will be preserved.


3.3 "usedforbuild"
--------------------

The default remains enabled.

Use case:
Allow building of gcc snapshots without breaking your own project.


3.3 "debuginfo"
--------------------

The default should remain disabled. Debuginfo packages can be rather large. So
we should keep them off for now. The real default value will be set in the
project config (which is not editable by the user atm). The default should be
in the config, so the default value can be inherited through the project config
inheritance. That way we can e.g. enable the debuginfo flag in our core distros
and all projects on top of it get rebuild with the new flag.

Of course debug repositories as used with 10.3/factory are another nice
solution for the problem.



A Appendix
============

A.1 Complex examples
----------------------


[[[
<package name="retty" project="home:darix">
...
<build>
<disable />
<enable repository="openSUSE_10.2" />
<disable arch="ppc" />
<build>
</package>
]]]

comments/critics welcome.

darix

--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >