pkg kde talk - Jan 2006 - kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested

Hello,

As you''re aware, there exists a clear circular dependency between 
kdelibs4c2a and kdelibs-bin. The binaries in kdelibs-bin link to the 
libraries in kdelibs4c2a. kdelibs4c2a has libraries which work extremely 
closely with the binaries in kdelibs-bin. Moreover, extremely few KDE 
packages depend on kdelibs-bin directly. They all assume that it gets 
pulled in by kdelibs4c2a, and during operation they do all assume that the 
binaries in kdelibs-bin are available, i.e. without kdelibs-bin nothing 
works.

So this makes the circle seem unbreakable, since re-uploading every KDE 
package, making them all depend on kdelibs-bin manually, would not be 
pleasant.

One solution would be to eliminate the kdelibs-bin package, merging it into 
kdelibs4c2a. But this violates the general practice of not shipping 
binaries in a library package, so there would have to be some general 
understanding about what we were doing before any such merge, to avoid too 
many later complaints, etc. (kdelibs4c2a is already a massive collection of 
libraries, and isn''t really designed to allow clean side-by-side
installs
of different KDE versions in the same hierarchy, so I don''t think
we''d lose
too much flexibility in practice, but still...)

But is this really necessary? You dealt with KDE woody --> sarge upgrade 
issues. How much of a problem is the kdelibs circular dependency? Any 
advice or suggestions on how to proceed or what to keep in mind would be 
welcome.

Thanks,
Christopher Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20060115/f9ea615b/attachment.pgp

On Sun, Jan 15, 2006 at 06:35:18PM -0500, Christopher Martin
wrote:
> Hello,
> 
> As you''re aware, there exists a clear circular dependency between 
> kdelibs4c2a and kdelibs-bin. The binaries in kdelibs-bin link to the 
> libraries in kdelibs4c2a. kdelibs4c2a has libraries which work extremely 
> closely with the binaries in kdelibs-bin. Moreover, extremely few KDE 
> packages depend on kdelibs-bin directly. They all assume that it gets 
> pulled in by kdelibs4c2a, and during operation they do all assume that the 
> binaries in kdelibs-bin are available, i.e. without kdelibs-bin nothing 
> works.
> 
> So this makes the circle seem unbreakable, since re-uploading every KDE 
> package, making them all depend on kdelibs-bin manually, would not be 
> pleasant.
Well technically that could have been done as part of the c++ transition,
could not it ?
> One solution would be to eliminate the kdelibs-bin package, merging it into
> kdelibs4c2a. But this violates the general practice of not shipping 
> binaries in a library package, so there would have to be some general 
> understanding about what we were doing before any such merge, to avoid too 
> many later complaints, etc. (kdelibs4c2a is already a massive collection of
> libraries, and isn''t really designed to allow clean side-by-side
installs
> of different KDE versions in the same hierarchy, so I don''t think
we''d lose
> too much flexibility in practice, but still...)
I think the core issues are whether 1) kdelibs4c2a needs kdelibs-bin to work,
whether 2) kdelibs-bin needs kdelibs4c2a and whether 3) it is possible to 
write a program that use kdelibs4c2a but do not need kdelibs-bin.

I suspect 2) is true, but am unsure about 1) and 3).

In any case there is a simple technical solution: make kdelibs4c2a
a dummy package that depends on kdelibs-bin and kdelibs4c2a-lib, where
the libraries are actually in kdelibs4-lib. Keep the shlibs pointing
to kdelibs4c2a, but tweak the build process so that kdelibs-bin depend
only on kdelibs4-lib.

Depending on the answer to 1) and 3) above, it might be possible to
transition to scheme where all KDE packages depend on kdelibs-bin
and then get rid of kdelibs4-lib.
> But is this really necessary? You dealt with KDE woody --> sarge upgrade
> issues. How much of a problem is the kdelibs circular dependency? Any 
> advice or suggestions on how to proceed or what to keep in mind would be 
> welcome.
This is hard to know, but the fact is that we will not be able to fix
that on a short time frame and we have to deal with dependencies in
stable release. 

This also break the dependency expectation: kdelibs-bin can be installed
before kdelibs4c2a.

This particular circular-dep does not seems too messy to fix so we
should settle on a clean solution and do it. The question being,
what the packages are doing really ? what are the real dependencies ?

Cheers,
Bill.

PS: is Chris Cheney MIA ?

On Wednesday 18 January 2006 08:51, Bill Allombert
wrote:
> > One solution would be to eliminate the kdelibs-bin package, merging it
> > into kdelibs4c2a. But this violates the general practice of not
> > shipping binaries in a library package, so there would have to be some
> > general understanding about what we were doing before any such merge,
> > to avoid too many later complaints, etc. (kdelibs4c2a is already a
> > massive collection of libraries, and isn''t really designed to
allow
> > clean side-by-side installs of different KDE versions in the same
> > hierarchy, so I don''t think we''d lose too much
flexibility in practice,
> > but still...)
>
> I think the core issues are whether 1) kdelibs4c2a needs kdelibs-bin to
> work
Yes. KDE apps will not work without kdelibs-bin installed. kdelibs-bin 
contains basic KDE services that apps expect to have running or available - 
dcop (the IPC system), I/O services for browsing file systems, http, etc.

I tried running a KDE app in an environment where I''d forcibly purged 
kdelibs-bin, and while it did run, it didn''t do anything. The file
dialogs
were empty, I got an endless series of warnings, etc. It was useless.
> 2) kdelibs-bin needs kdelibs4c2a
Yes.
> 3) it is possible to write a program that use kdelibs4c2a but do not need
> kdelibs-bin.
I suppose it might be possible somehow, but it wouldn''t be a normal KDE
application, certainly. For all intents and purposes, all KDE apps need 
both -bin and the libs.
> In any case there is a simple technical solution: make kdelibs4c2a
> a dummy package that depends on kdelibs-bin and kdelibs4c2a-lib, where
> the libraries are actually in kdelibs4-lib. Keep the shlibs pointing
> to kdelibs4c2a, but tweak the build process so that kdelibs-bin depend
> only on kdelibs4-lib.
>
> Depending on the answer to 1) and 3) above, it might be possible to
> transition to scheme where all KDE packages depend on kdelibs-bin
> and then get rid of kdelibs4-lib.
Yes, that would work. But I view this as more complex than necessary. Given 
the answers to 1), 2) and 3), I view merging kdelibs-bin into kdelibs4c2a 
as simpler, and involving virtually no work on the part of 3rd party 
maintainers (only a handful of packages depend on kdelibs-bin directly, and 
the new kdelibs4c2a can Provide: kdelibs-bin).

Since the separation between kdelibs-bin and kdelibs4c2a is not functional 
(i.e. they are always used together) keeping them apart seems unnecessary, 
and (as far as I can tell) only satisfies the notion that libraries and 
programs should be separate, even when, in this case, they are not used 
separately. But if people view my solution as too radical, then your 
proposal seems OK at first consideration.
> > But is this really necessary? You dealt with KDE woody --> sarge
> > upgrade issues. How much of a problem is the kdelibs circular
> > dependency? Any advice or suggestions on how to proceed or what to
keep
> > in mind would be welcome.
>
> This is hard to know, but the fact is that we will not be able to fix
> that on a short time frame and we have to deal with dependencies in
> stable release.
Yes, it would be nice to have this fixed, so the post-Etch KDE4 (using Qt4) 
transition is less messy.
> PS: is Chris Cheney MIA ?
He certainly isn''t active in KDE packaging, so unless there is some
other
area of the project where he''s active, I''d say yes,
he''s MIA.

Cheers,
Christopher Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20060118/88e131b3/attachment.pgp

* Christopher Martin [Wed, 18 Jan 2006 12:42:27 -0500]:
> Yes, that would work. But I view this as more complex than necessary. Given
> the answers to 1), 2) and 3), I view merging kdelibs-bin into kdelibs4c2a 
> as simpler, and involving virtually no work on the part of 3rd party 
> maintainers (only a handful of packages depend on kdelibs-bin directly, and
> the new kdelibs4c2a can Provide: kdelibs-bin).
> Since the separation between kdelibs-bin and kdelibs4c2a is not functional 
> (i.e. they are always used together) keeping them apart seems unnecessary, 
> and (as far as I can tell) only satisfies the notion that libraries and 
> programs should be separate, even when, in this case, they are not used 
> separately. But if people view my solution as too radical, then your 
> proposal seems OK at first consideration.
  Weeell, it''d be an option, but then we have this liiittle section
from
  Policy:

  8.2. Run-time support programs
  ------------------------------

     If your package has some run-time support programs which use the
     shared library you must not put them in the shared library package.
     If you do that then you won''t be able to install several versions
of
     the shared library without getting filename clashes.

     Instead, either create another package for the runtime binaries (this
     package might typically be named `<libraryname>-runtime'';
note the
     absence of the <soversion> in the package name), or if the
development
     package is small, include them in there.

  Note the "must not"...

  Cheers,

-- 
Adeodato Sim?                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
<dato>
http://lists.ubuntu.com/archives/ubuntu-news/2005-December/000033.html
<dato> these ubuntu-news are all about warm fuzzy feelings, how much we
rock
       and, specially, love each other.
<isaac> es como la distribucion de los teletubbies
<dato> that may be the best description of ubuntu I''ve ever heard

Adeodato Sim? <dato@net.com.org.es> writes:
> * Christopher Martin [Wed, 18 Jan 2006 12:42:27 -0500]:
>
>> Yes, that would work. But I view this as more complex than necessary.
Given
>> the answers to 1), 2) and 3), I view merging kdelibs-bin into
kdelibs4c2a
>> as simpler, and involving virtually no work on the part of 3rd party 
>> maintainers (only a handful of packages depend on kdelibs-bin directly,
and
>> the new kdelibs4c2a can Provide: kdelibs-bin).
>
>> Since the separation between kdelibs-bin and kdelibs4c2a is not
functional
>> (i.e. they are always used together) keeping them apart seems
unnecessary,
>> and (as far as I can tell) only satisfies the notion that libraries and
>> programs should be separate, even when, in this case, they are not used
>> separately. But if people view my solution as too radical, then your 
>> proposal seems OK at first consideration.
>
>   Weeell, it''d be an option, but then we have this liiittle
section from
>   Policy:
>
>   8.2. Run-time support programs
>   ------------------------------
>
>      If your package has some run-time support programs which use the
>      shared library you must not put them in the shared library package.
>      If you do that then you won''t be able to install several
versions of
>      the shared library without getting filename clashes.
>
>      Instead, either create another package for the runtime binaries (this
>      package might typically be named
`<libraryname>-runtime''; note the
>      absence of the <soversion> in the package name), or if the
development
>      package is small, include them in there.
>
>   Note the "must not"...
I think that''s a stupid requirement in policy (and means the Qt4
packages violate policy).  kdelibs don''t coexist nicely anyway AFAIK,
so
the rationale for that requirement doesn''t apply.

-- 
Captain Logic is not steering this tugboat.

On Wednesday 18 January 2006 12:54, Adeodato Sim? wrote:
>   Weeell, it''d be an option, but then we have this liiittle
section from
>   Policy:
>
>   8.2. Run-time support programs
>   ------------------------------
>
>      If your package has some run-time support programs which use the
>      shared library you must not put them in the shared library package.
>      If you do that then you won''t be able to install several
versions of
>      the shared library without getting filename clashes.
>
>      Instead, either create another package for the runtime binaries
> (this package might typically be named
`<libraryname>-runtime''; note the
> absence of the <soversion> in the package name), or if the
development
> package is small, include them in there.
>
>   Note the "must not"...
True, we''d probably want to get Release Team blessing. In this case, I
don''t
think that the rationale ("you won''t be able to install several
versions of
the shared library") applies, since KDE isn''t designed for
multiple,
side-by-side installs; kdelibs4 will never be installable alongside 
kdelibs5. The need for KDE binaries (currently in kdelibs-bin) precludes it 
(amongst many other things). The binaries are so closely tied to the 
libraries in KDE, that the separation doesn''t give anyone any sort of 
advantage, added flexibility, etc.

Since they already depend on each other, eveyone has both installed anyway. 
And re-uploading every application with a kdelibs-bin dep added... I
don''t
want to do that, though maybe for KDE4 we could try to change the policy... 
but again, it wouldn''t actually help anything or result in any
improvements
or advantages.

But yes, we''d need to establish some sort of understanding that KDE was
an
exception to the policy before proceeding. And the KDE team would have to 
support the idea - not just me :)

Chris

* Christopher Martin [Wed, 18 Jan 2006 14:30:35 -0500]:
> But yes, we''d need to establish some sort of understanding that
KDE was an
> exception to the policy before proceeding. And the KDE team would have to 
> support the idea - not just me :)
  I certainly don''t reject it. Only wanted to point out that such
  section of policy would have to be taken care of. (And perhaps a
  proper explanation in the changelog may qualify for "take care of".)

  Cheers,

-- 
Adeodato Sim?                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
He has never been known to use a word that might send a reader to the
dictionary.
                -- William Faulkner (about Ernest Hemingway)

> as simpler, and involving virtually no work on the part of 3rd party 
> maintainers (only a handful of packages depend on kdelibs-bin directly, and
> the new kdelibs4c2a can Provide: kdelibs-bin).
> 
> Since the separation between kdelibs-bin and kdelibs4c2a is not functional 
> (i.e. they are always used together) keeping them apart seems unnecessary, 
> and (as far as I can tell) only satisfies the notion that libraries and 
> programs should be separate, even when, in this case, they are not used 
> separately. But if people view my solution as too radical, then your 
> proposal seems OK at first consideration.
I have taken a bit of time to look at the packages.

One issue I am unsure is how kdelibs4c2 use kdelibs-bin ? I will assume
 the library forks kdelibs-bin daemons.

Currently kdelibs4c2 is a pure librarie packages. It has an exact-version
depend on kdelibs-bin and kdelibs-bin as a >= version depend on
kdelibs4c2.

This is messy because the exact-version dependency cannot be satisfied 
during upgrade, so there is a definite possibility kdelibs4c2 launch 
a old, incompatible, daemon.

We normally want to allow several major versions of pure libraries
packages to be co-installable, however the same-version dependencies
prevent that. However if multi-arch is implemented, there still the
possibility to have both 32bit and 64bit at the same time.
As far as I understand the design of KDE IPC allows 32bit and 64bit
processes to work together, so it might make sense to install 
kdelibs4c2-32bit, kdelibs4c2-64bit and kdelibs-bin-32bit.

If you merge kdelibs-bin in kdelibs4c2, then kdelibs5 will have to
conflict with kdelibs4c2. I don''t think this is a big deal given
the exact-version depdends will forbid kdelibs4c2 and kdelibs5 to
be co-installable.

Alternatively, you can fix the co-installability problem by versioning
the path to the binaries, e.g. moving them to /usr/lib/kdelibs4/ and
make sure the libraries use the correct path.

Cheers,
Bill.

Le Ven 20 Janvier 2006 23:17, Bill Allombert a ?crit :
> Alternatively, you can fix the co-installability problem by
> versioning the path to the binaries, e.g. moving them to
> /usr/lib/kdelibs4/ and make sure the libraries use the correct path.
honnestly, there is no point in doing that. This would make the 
packaging even more painfull that it is now, with almost no gain.

The only way to achieve reall co-instability is to do as gentoo does : 
make KDE live in /usr/kde/x.y/ which would be a major policy violation, 
and which makes no sense at all.

your arguments about multiarch *are* valid and deserve some pondering 
(especially since users may want a 32bits konqueror to be able to use 
macromedia flash plugin, or sun''s java plugin...). but honnestly, 
beeing able to co-install different kdelibs *versions* has no point at 
all, since no one would really take advantage of this.


In the KDE world, most applications migrate to the new kdelibs/kdebase 
with each new KDE release. I''ve really problems to think of a situation
where co-instability would really help any user. Moreover, it''s not 
really a feature that our users want. Developpers have their own 
checkout of kde-HEAD in their home, and adjust their KDE_PATH to 
$HOME/kde-head/ and the trick is done, they have two version of KDE on 
the same system.


-- 
?O?  Pierre Habouzit
??O                                                madcoder@debian.org
OOO                                                http://www.madism.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20060120/819cc103/attachment.pgp

On Fri, Jan 20, 2006 at 11:40:25PM +0100, Pierre Habouzit
wrote:
> Le Ven 20 Janvier 2006 23:17, Bill Allombert a ?crit :
> > Alternatively, you can fix the co-installability problem by
> > versioning the path to the binaries, e.g. moving them to
> > /usr/lib/kdelibs4/ and make sure the libraries use the correct path.
> 
> honnestly, there is no point in doing that. This would make the 
> packaging even more painfull that it is now, with almost no gain.
Well, if you are not interested in supporting co-installability, then
I support the move to merge kdelibs-bin to kdelibs4c2a. This is the
only simple solution that remove the real problem, namely the
exact-version dependency of kdelibs4c2a on kdelibs-bin.

Cheers,
Bill.