Adding release team on CC so they are aware of the transition. @Release team, this is a very early warning, the 4.6/4.8 transition won't happen for squeeze (though the libxfce4panel split might).
On jeu., 2010-04-29 at 22:45 +0200, Lionel Le Folgoc wrote: > Hi there, > > I've been thinking lately about the best way to prepare the upload of > xfce4-panel 4.8 (right, it's for the future, after squeeze, but there's > already some branches in desktop/branches/experimental :p). I spoke with > Corsac a few weeks ago, but we probably forgot already what we said, so > here is a(n attempt of) summary. > > The issue is that xfce4-panel 4.8 breaks the ABI, so any plugin built > against xfce4-panel 4.6 will break and must be rebuilt (no API change > though, so it can be handled by binnmus I guess). However, panel plugins > currently depend on xfce4-panel (>= 4.6), so nothing prevents apt from > upgrading xfce4-panel to 4.8 when a 4.6 plugin is still installed… > > So far, here are some ideas: > > 1) Keep the packaging as-is: > * upload a new 4.6 revision to add xfce4-panel (<< 4.7.0) to shlibs > * binnmu all plugins > * (release squeeze :p) > * upload 4.8 panel with shlibs (>= 4.7.0) > * binnmu all plugins again (and a user can't update the panel unless > all plugins have been rebuilt) > > It's the simplest/easiest one (can also be done with virtual packages > 'xfce4-panel-4.6-abi' and 'xfce4-panel-4.8-abi' if we don't want to play > with versioned shlibs, but that looks a bit overkill). > > However, a package split could be considered, as programs like thunar > that provide a panel plugin don't need to depend/recommend xfce4-panel, > but only its library (since it's not their main feature). > > 2) Split bin/libs: > * upload a new 4.6 revision with a new libxfce4panel1 split binary > package > * binnmu all plugins, they'll depend on the lib only then > * (release squeeze, o'rly?) > a) > * upload 4.8 panel, the library pkg is libxfce4panel-1.0-3, and > Breaks: xfce4-panel (<< 4.7.0) > * binnmu all plugins again, they'll depend on the new lib only > or > b) > * upload 4.8 panel, the library pkg is libxfce4panel-1.0-3, and > the xfce4-panel pkg Breaks: libxfce4panel1 (<< 4.7.0) > * binnmu all plugins again > or > c) > * upload 4.8 panel, the library pkg is libxfce4panel-1.0-3, and > Breaks: libxfce4panel1 (<< 4.7.0) > * binnmu all plugins again > > The two first ideas (2a & 2b) seem semantically ok, but afaui, they are > not enough to ensure a smooth transition: in a), it's possible to keep a > 4.6 plugin installed at the same time as the 4.8 panel, and in b), a > plugin for 4.8 can be installed at the same time as the 4.6 panel… > > The last idea (2c) works fine in this aspect, but doesn't look "right", > i.e. libxfce4panel-1.0-3 doesn't "really" break libxfce4panel1, it's > not the correct relationship… > > Voila :) > > I don't have a strong preference, as long as it works, but I think that > the split might be useful. > > Ideas (maybe I forgot an obvious solution), thoughts, rants[*]? > Solution 1 seems the easiest but yeah, it'd be nice at some point to split libxfce4panel. Maybe it'd make sense to do it _after_ the 4.8 split, but I'm not sure if it's really possible to do both the 4.8 + split in the squeeze+1 timeframe. Cheers, -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part
