[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: renaming sylpheed-claws-gtk2-* to claws-mail-*



On Tue, 2 Jan 2007 03:32:10 -0800
Steve Langasek <vorlon@debian.org> wrote:

> On Tue, Jan 02, 2007 at 12:12:48PM +0100, Ricardo Mones wrote:
> > Steve Langasek <vorlon@debian.org> wrote:
> 
> > > On Fri, Dec 29, 2006 at 10:58:02AM +0100, Ricardo Mones wrote:
> > > >   So the question is to do that renaming now or to do it after Etch.
> 
> > > >   I'd be happy to do the switch now and forget s-c-gtk2 packages, but
> > > > given current Etch status I understand it may not be possible. Please
> > > > let me know and/or the changes required to make this possible.
> 
> > > Given the large number of binary packages involved and the potential
> > > interplay between them, I would prefer postponing this until lenny.
> 
> >   Which interplay are you referring to? The plugins are shared libraries
> > loaded by the main program (claws-mail) to extend it's functionality,
> > nothing more. There's a unique interdependency between plugins (pgpinline
> > and pgmmime require pgpcore) but it's already present and solved in
> > current packages.
> 
> Are all of the plugin packages being renamed along with the application?

  Yep, that's the plan, all plugins provided withing program sources and
also the extra plugins are renamed.

> Will each of these packages need to conflict/replace the old package name
> to ensure a smooth transition?

  Technically speaking that's not needed as they're installed in a different
location, only the main package needs to conflict because it provides also a
symlink with the old binary name (sylpheed-claws-gtk2). That can be easily
removed. Appart from that new and old packages could perfectly coexist.

  If ensuring a smooth transition includes that apt-get upgrade/dist-upgrade
does the package switching then as I understand it only a Provides: with the
old package name would be required in each new package. That's currently not
implemented in current packages. I may be wrong here, though.
 
> Are the dependencies on sylpheed-claws-gtk2 auto-generated from the
> build-dependency somehow, or will they need to each be updated manually for
> the transition?

  Generated from the libsylpheed-claws-gtk2-dev/libclaws-mail-dev version in
the build-depends. Only this one needs to be manually updated, plugins'
dependency is obtained from this one.
 
> Not all of the plugin packages are from the sylpheed-claws-gtk2 source
> package; will the multiple source packages need to be updated in testing
> together, and will the package relationships reflect this to prevent any
> accidents?

  Indeed, the new claws-mail-extra-plugins package is already depending on
libclaws-mail-dev. This one should be introduced in testing after
claws-mail (which provides libclaws-mail-dev).

> Will the build-dependencies of s-c-gtk2-extra-plugins change on package
> rename, will the change prevent or allow the package to be built with the
> current libsylpheed-claws-gtk2-dev, and what are the consequences of this
> if any?

  Yes, the change, as said, and building with libsylpheed-claws-gtk2-dev is
not allowed. I cannot see any consequences, they need libclaws-mail-dev to
be built correctly for claws-mail.
 
> These are the kinds of issues that constitute "interplay", and make this a
> potentially risky update.  The release team doesn't have time right now to
> help make sure the transition is a smooth one, and we can't really afford a
> rough one, sorry.

  Ok, fine enough for me, I won't waste anymore your time. 

  Anyway I'd like this dialog to continue after releasing to ensure this a
succesful transition, with you or any other RM if you don't have time.
 
  thanks in advance,

P.S.: Please Cc me, I'm not subscribed to debian-release.
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «The ripest fruit falls first. -- William Shakespeare, "Richard II"»

Attachment: signature.asc
Description: PGP signature


Reply to: