From Mandriva Community Wiki

Caution !
THIS IS VALID FOR GNOME 3 and glib 2.30+ RELATED PACKAGES.

Packages needing the migration (or first inclusion in the distribution)

List taken from http://fedoraproject.org/wiki/Features/Gnome3#Details, it may not be the same for Mandriva, or needs updating

The full list of affected packages is present at GNOME:

https://live.gnome.org/GnomeDeveloperKit/PackageList

Build packages which provide gtk modules for gtk2 and gtk3 (tracked [upstream]):

Make GTK-using libraries parallel-installable, or port them to GTK3, or drop their GTK dependency:

Switch to the dbus-based accessibility stack (Done) Implement data migration for applications that are ported from GConf2 to dconf

Implement fallback from the shell to gnome-panel+metacity for unsupported hardware (in progress) All system status indicators must use symbolic icons, others are optional

Make sure applications keep working and don't run into mixed linkage against both gtk2 and gtk3 via gtk-using libraries. Currently known problems:

Current mixed linkage problems that need to be addressed:

Package application naming

We follow as much as possible upstream names.

Basic requires for every GNOME 3 application

• To be completed

SPEC helper macros for GNOME

SPEC Layout

This is a temptative attempt for GNOME packages, not a formal recommandation for now (RFC for cooker).

BR sould be used in the form of:

BuildRequires: pkgconfig(foo)

instead of

BuildRequires: foo-devel

Template

Name:          <name>
Summary:       <summary>
Version:       <version>
Group:         Graphical desktop/GNOME
License:       GPLv3
URL:           http://www.gnome.org
Release:       %mkrel 1
Source:·       ftp://ftp.kde.org/pub/kde/stable/%version/src/kfoo-%version.tar.bz2

Library policy

Every library should be splitted with their proper soname. There's usual complain to have too many subpackages, but this is just a excuse for laziness. Some reasons behind splits:

• Developers need to change soname and binary api. If we have library inside package, upgrade would be hard
• Legacy applications should need the library only, no the whole package.
• Development packages can require just library packages, not the whole package.

Package should not requires libraries explicitely. Mandriva RPM build already set the necessary dependencies automatically

How it will be on spec file using standard Mandriva style ?

%define kfoo_major 1
%define libkfoo %mklibname kfoo %{kfoo_major}

%package -n %libkfoo
Summary: Kfoo library
Group: System/Libraries

%description -n %libkfoo
Kfoo library.

%files -n %libkfoo
%defattr(-,root,roo,-)
%_kde_libdir/libkfoo.so.%{kfoo_major}*

Patch policy

Every patch for a GNOME package SHOULD have this header :

#
# Description: 
# Forwarded: 
# Bug: 
# Author: 
#

Other pages for gnome 2.32 to 3.2 migration

http://live.gnome.org/ThreePointZero/AppIntegration

http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

https://build.opensuse.org/project/packages?project=GNOME%3ASTABLE%3A3.2

http://fedoraproject.org/wiki/Features/Gnome3#Scope