[Pkg-xfce-devel] Thoughts about the future migration to xfce4-panel 4.8

Yves-Alexis Perez corsac at debian.org
Thu Apr 29 21:03:08 UTC 2010

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20100429/b04cb755/attachment.pgp>

More information about the Pkg-xfce-devel mailing list