[Pkg-ime-devel] The upstream devlopment of SCIM packages

Osamu Aoki osamu@debian.org
Fri, 28 Jan 2005 07:46:40 +0100


On Thu, Jan 27, 2005 at 11:25:41PM -0600, Ming Hua wrote:
> On Sun, Jan 23, 2005 at 07:28:33PM +0100, Osamu Aoki wrote:
> > Hi,
> > 
> > On Sat, Jan 22, 2005 at 11:21:34PM -0600, Ming Hua wrote:
> > > The main part, scim, is entering beta for the new 1.1.x development
> > > branch (which will released as 1.2.0 eventually).  I haven't looked at
> > > the packages yet, but it seems they are not binary compatible with 1.0.x
> > > series.  James Su has released the new scim-chinese (renamed as
> > > scim-pinyin, see below) and scim-tables for 1.1.x series, but I'm not
> > > sure about scim-hangul, scim-uim and scim-m17n status.
> > 
> > Me either.  Any idea for backword compatibleness?  (The way they have
> > been discussing seems to indicate libm17n has been quite up to date and
> > suggests scim-m17n has been working for testing.  I may be wrong here.)
> 
> Source compatibility (API), perhaps.  Binary compatibility (ABI), most
> likely not.  But if ABI is broken, they are supposed to bump the SONAME
> of libscim library.  I'll try to figure this out later (if nobody does
> it first :-).

Thanks.

> > > The imengine plugin for scim-tables will be separated from scim and put
> > > into scim-tables package.  This means we can't have a arch:all package
> > > for scim-tables anymore.  Most likely I am going to add a arch:any
> > > scim-imengine-table package to the scim-tables source package.
> > 
> > You mean to keep arch:all part to be binary scim-tables package and add
> > binary scim-imengine-table package.  THat sounds good to me.
> 
> Yes that is what I meant, a binary package scim-tables-bin, for example.

Or scim-tables-common  (Some package use this too.  Emacs is the only
with one -bin-common .)

> > But if you
> > add new binary package, you need to get FTP master approve it to even
> > upload to experimental, I think.  We may have to use
> > people.debian.org/~osamu/packages type URL for now.
> 
> But if it goes through NEW queue when uploaded to experimental, does it
> need to go through NEW again when it's uploaded to unstable?  My
> impression is it doesn't, so it may actually save some time.  However I
> don't insist, your directory on people.d.o is perfectly fine.

You may be right here.  But they are very slow on NEW (unstable) even
for these existing source package.  Do not expect too much.

Let'd do both.  It does not hurt.

> > > There are also messages from Hong Kong developers about adding tables
> > > into scim-tables-zh package.  The are in scim-tables 0.5.x (for scim
> > > 1.1.x and 1.2.x), but James has said he won't backport them to 0.4.x
> > > (for scim 1.0.x and what Debian packages) himself.  We are most likely
> > > going to end up backporting them ourselves, it should not be too hard,
> > > though.
> > 
> > We(?) -- who :-)
> 
> Err, I meant Debian maintainers instead of upstream authors.  Osamu, I
> think you remember the Email from Roy Chan.  I hope he can do this for
> us.  :-)

Same here.

> > I guess once some one who is competent and who needs it give us a good
> > tested patch, We(Ming and I) have to add them to package as dpatch.
> > Unless some people from HongKong test them and happy, it will be not
> > good move to add them.
> 
> Roy Chan sent a mail to Osamu and I about two weeks ago proposing this
> change.  He is a Hong Kong user, and I think Osamu was thinging of him
> when he says ``some one competent''. :-)  I'm going to ping him for the
> status, and if he is too busy (to make the change before sarge), I think
> I can try my hands on the two tables already imported in scim-tables
> 0.5.x, i.e., backporting.  I am sure if I did this, I can find some
> users to do the testing.
> 
> > > If I still
> > > have time after that, I am planning to package scim 1.1.x packages to
> > > experimental.
> > 
> > As I said, you may want to consider alternative location.  I can offer
> > space at people.d.o
> 
> Thanks.  I have no preference, either way is perfectly fine.  Now I just
> need to get some time to do the real packaging instead of talking...

Osamu