Re: Gnome to be removed from debian?
On Fri, 12 Feb 1999, Ben Collins wrote:
> On Fri, Feb 12, 1999 at 11:08:34PM -0500, Brian Almeida wrote:
> > On Fri, Feb 12, 1999 at 10:45:46PM -0500, Ben Collins wrote:
> > > That's the problem, there should only be one of each major version (ie
> > > 1.0, 1.1, 1.2, etc.) Not each minor version increase. This isn't your
> > > fault, it's the fault of the libgtk maintainer, and it's causing you,
> > > other maintainers that link against libgtk and users lots, of problems.
> > That's what the libgtk maintainer HAD to do. The soname changes with each
> > 'minor' release, breaking all apps compiled against it with each release.
> > The current situation isn't perfect, but that's a bug in dpkg, not in the way
> > the libgtk packages are made.
>
> That's why we have shlibs deps. Read the packaging manual. He/she needs to
> setup the shlibs to be specifically version dependant as in
> "libgtk1.1 (= 1.1.15-4)". This is _exactly_ why we have them. The only
> reason for doing the way they are is to allow lots of releases and not
> break leave anything broken. It is obvious however, that fewere releases
> into unstable with a better versioning would be much better. I think
> most would agree (users and maintainers) that they would rather things
> break and know what to do about it than to wonder which of the 6
> versions they are going to need.
I'm confused.
These are *major* version increases - if you define major as soname.
Superficially, they look like minor versions. However, they are soname
changes. Gtk is under development, so the API keeps changing. The gtk
upstream maintainers are doing the right thing by changing the soname
every release, since the API changes every release.
And then, our GTK maintainer is 'doing the right thing' by making seperate
packages, since our policy is correctly to have separate packages for
distinct sonames.
I don't see how shlibs will help this?
The real problem is upstream packages, which continue to need particular
versions of Gtk. Someone will compile gX, and find that gX needs gtk >=
1.1.13, so they'll hassle Ben to compile a new gtk package.
For this reason, we actually 'need' at the moment almost all the versions
of gtk we have. If you want to see which gtk packages use each version,
try
apt-cache showpkg libgtk1.1.XX
Which does point out - why does apt think libgtk1.1.15 depends on
libgtk1.1.X, X=5...14. Looks like a bug in apt-cache to me - it
'replaces' this versions, not depends. Come to that, why does it replace
them?
Anyway, that aside, what is the answer to this problem:
Debian developer wants to package funky package A.
A requires libgtk1.1.456
What do we do? Currently, our hard-working gtk maintainer has made the
latest libgtk version available. I don't see an alternative..
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: