Re: Using python + pygtk in Desktop modules (was Re: RevisitingtheGnome Bindings)



On Tue, 2004-09-28 at 16:40 +0200, Murray Cumming wrote:
> >> When a new version is released with python-2.4, the *new* pygtk-2.4
> >> package distributed with *this* version of the operating system would be
> >> compiled against python-2.4 and install its files into the python-2.4
> >> versioned module directory.
> >>
> >> Is this not how it works at the moment? If not, why not?
> >
> > When all of your libraries are distributed by the OS vendor, sure.
> >
> > Say though that you have a third-party app written for pygtk which
> > includes its own libraries that are installed solely for python 2.3.
> > When python 2.4 comes along, that app *must* continue using 2.3.  Which
> > means the app must be hard coded to only invoke the python 2.3 binary.
> > Which is distribution specific.  Which forces app authors to release
> > updated packages for their apps for newer distributions.
> 
> Surely distributions are unlikely to move the python-2.3 binary? I admit
> that I'd prefer some more generic way of specifying the python version,
> but choosing that !# just seems like part of the packaging to me.

Yes - part of the packaging.  Which is the problem, as explained below.

> 
> >  Which
> > effectively kills any purpose of having ABI stability.
> 
> It makes it difficult to have cross-distro packages, but that's not what
> we're talking about here.

Not just cross distro, cross distro release.  A package has to be made
for every architecture (for compiled modules) of every version of every
distro that you want to support.

And it's not just packages, it's any app.  GNOME is great for third-
party developers because they can just push out their app in a (mostly)
LSB RPM or a tarball or automatic installer or Autopackage or whatever,
and have it Just Work(tm), because the GNOME ABI is stable and you know
for sure that any distro with the version you targeted or higher can run
the app.  This makes third-party packages for GNOME apps actually
feasible without needing a massive compile farm or expecting users to
compile from source.

Honestly, if you expect all apps to be repackaged like this, why are we
wasting time on ABI stability for _any_ GNOME module?  It buys us
*nothing* in that case.  Say GTK 2.6 is incompatible with GTK 2.4; if
you are forced to repackage for every release of every distro, who
cares?  You don't target GTK 2.4's ABI, you target an OS's ABI, and the
ABI of whichever libraries that OS has.  FC3 has a different GTK than
FC2?  Who cares if GTK maintains a stable ABI, you're supposed to
recompile the app for each OS release anyhow - right?

ABI is 100% about packaging, cross-distro and cross-release support, and
ease of transferring binaries around without needing recompilation.

By your logic, the only thing we need is a stable API, as ABI is
useless.

> 
> 
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




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