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: [[[ <!-- tbd: type name --> xs:sequence ... ... ]]] 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: [[[ <!-- tbd: type name --> <!-- tbd: type name --> xs:sequence xs:sequence xs:sequence ... ... xs:sequence ... ... ]]] 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@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org