Here're the minutes from the meeting. * log entries in .changes file Just a simple "Update to version x.y" is not valid but happens far too often. .NEWS file for major changes? Goal: present the changes done to packages to users in a good way We have not found any appropriate solution. We will continue with the current practice: - packages need to have valid changes entries - a version update should include the highlight of the changes and not just "Update to version x.y" * Autofs5 instead of autofs4? autofs5 is a complete rewrite, moving autofs from kernel to userland. It complies with other technologies, e.g. automounter from Sun, and therefore solves many open feature requests. Existing setup will continue to work. We decided to move forward with the switch. * Smaller systems - what can be done? Goal: A system with 128 MB of space. Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package. For languages we discussed previously already the following and will implement this now: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. To be continued next time. * Updating openSUSE: What options do we have - what will we advocate? - Boot from CD? - zypper update? - System Update? "System Update" is more about bringing the system in a consistent state. It did not work for us with our SLE service packs. Many developers and the community like to have an easy way to update their system to the latest and greatest version of the distribution - without rebooting. Currently there's no algorithm in place that handles different repositories correctly, just consider what should happen in the case of kernel and kmp package update with different repositories: * Update new kmp but keep old kernel * Update kernel and keep old kmp * Update kmp and kernel We need to define as well which repository is upstream, e.g. for moving from 10.2 to 10.3. Officially supported is currently only the system update from the installation system (after booting from CD). Update from a running system would need extra QA (this is currently not supported and not tested). Users understand that this does not work from 10.2 to 10.3 but not if they update daily or from e.g. Alpha2 to Alpha3. But both scenario are the same challenge. The underlying problem is package splits, package renames and package drops. This might need further policies which would lead to e.g. two perl versions installed in parallel for the transition. The challenge is not the leaf package but the core system. Note: Patterns are not updated with a zypper update. To achieve updating in a running system, we would need to enforce better policies for package splits, renames and drops and need to fix zypper to handle all this properly. This would still be an expert option since it might need user interaction for some choices. AI: aj to discuss further in smaller round whether what needs to be done. * TeXLive switch We have TeXLive now in the distribution but packages still use the old teTeX packages for building. Every packager should change the requires of their packages so that we can soon obsolete the old teTeX packages. We also have to get packages like cjk-latex, jadetex and xmltex working with the new TeXLive system. AI: send email to opensuse-packaging to inform packager what needs to be done for their packages. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126