--nextPart1493043.S8CUZO964q
Content-Type: multipart/alternative;
boundary="Boundary-00=_75jHIn4dgVUPBQI"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--Boundary-00=_75jHIn4dgVUPBQI
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On Sunday 04 May 2008, K=E5re S=E4rs wrote:
> Hi,
>
> I have now moved ksaneplugin to kdegraphics, but not libksane.
>
> I did not move libksane because of circular dependency problems:
> Gwenview -> libkipi (kipi-plugins) -> libksane
So basically acquireimages would depend on libksane (which we want to move=
=20
out of extragear) and moving it to kdegraphics would make that kipi plugin=
=20
depend on kdegraphics?
Looks like our options are to
1. Move libksane to kdelibs since multiple applications use it.
2. Make a new kdegraphicslib or similar and make extragear/libs/kipi-plugin=
s=20
optionally depend on it and have kdegraphics depend on it.
3. Leave libksane in extragear/libs even though it is ready to be moved int=
o=20
KDE and have kdegraphics optionally depend on it.
4. Move libksane to kdegraphics and make extragear/libs/kipi optionally=20
depend on it. This depends on stuff in kdegraphics not depending (even=20
optionally) on things in extragear/libs/kipi though, which Gwenview does.
I don't like option 3 because eventually some other library will be ready t=
o=20
leave extragear and we'll likely have the same issue. Do we have a set=20
policy for how libraries migrate out of extragear, or just applications?
If don't like option 4 because of the circular dependencies involved. It's=
=20
just not a good idea to allow circular dependencies to exist.
If libksane is small enough I'd say use option 1, otherwise I'd say we need=
=20
to do option 2 (or something similar). Anyone have other thoughts?
Regards,
- Michael Pyne
--Boundary-00=_75jHIn4dgVUPBQI
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On Sunday 0=
4 May 2008, K=E5re S=E4rs wrote:
> Hi,
>
> I have=
now moved ksaneplugin to kdegraphics, but not libksane.
>
> I did =
not move libksane because of circular dependency problems:
> Gwenvi=
ew -> libkipi (kipi-plugins) -> libksane
So basicall=
y acquireimages would depend on libksane (which we want to move out of extr=
agear) and moving it to kdegraphics would make that kipi plugin depend on k=
degraphics?
Looks like =
our options are to
1. Move lib=
ksane to kdelibs since multiple applications use it.
2. Make a n=
ew kdegraphicslib or similar and make extragear/libs/kipi-plugins optionall=
y depend on it and have kdegraphics depend on it.
3. Leave li=
bksane in extragear/libs even though it is ready to be moved into KDE and h=
ave kdegraphics optionally depend on it.
4. Move lib=
ksane to kdegraphics and make extragear/libs/kipi optionally depend on it. =
This depends on stuff in kdegraphics not depending (even optionally) on th=
ings in extragear/libs/kipi though, which Gwenview does.
I don't lik=
e option 3 because eventually some other library will be ready to leave ext=
ragear and we'll likely have the same issue. Do we have a set policy for h=
ow libraries migrate out of extragear, or just applications?
If don't li=
ke option 4 because of the circular dependencies involved. It's just not a=
good idea to allow circular dependencies to exist.
If libksane=
is small enough I'd say use option 1, otherwise I'd say we need to do opti=
on 2 (or something similar). Anyone have other thoughts?
Regards,
- Michael =
Pyne
--Boundary-00=_75jHIn4dgVUPBQI--
--nextPart1493043.S8CUZO964q
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQBIHj6AqjQYp5Omm0oRAiI/AJwN/HoGAXgtd8sZIqobR3eiKSpC0gCfYcpX
FV8HiztcQzWZ/PqDXMZ5548=
=Tffj
-----END PGP SIGNATURE-----
--nextPart1493043.S8CUZO964q--