state of jed-extra

Jörg Sommer joerg at alea.gnuu.de
Fri Jun 9 16:19:06 UTC 2006


Hallo G.,

G. Milde schrieb am Fri 09. Jun, 11:04 (+0200):
> On  8.06.06, Jörg Sommer wrote:
> > G. Milde schrieb am Thu 08. Jun, 11:24 (+0200):
> > > > > > > > G. Milde schrieb am Wed 31. May, 16:00 (+0200):
> > > > > > > > > * updating jed-common, jed, xjed, and jed-extra in one run failed:
> 
> 
> > But jed-common does not depend on jed. It can be installed without the
> > jed package. Then it would also fail.
> 
> Should we mark jed-common and jed-extra as depending on jed|xjed?

Maybe jed-extra, but not, really never jed-common. This would introduce a
dependency cycle which is evil.

> Still I think that moving the 
> > >   
> > >   Conflicts: jed-extra (<= 1.0-1)
> > > 
> > > from jed-common to jed and xjed is "the right way"
> 
> > >  * jed 0.99.18 and xjed 0.99.18 use SLang 2, which breaks some
> > >    of the modes in jed-extra 1.0-1.
> > 
> > But I don't know if this would justify a conflict. I'm in doubt if the
> > conflict on jed-extra is right. If I remember correctly the conflict
> > field is for conflicts of package on dpkg's view. Not for "A is not
> > usable with B."
> 
> Policy 3.5
> 
>   Every package must specify the dependency information about other
>   packages that are required for the first to work correctly.

The question is, was is „the dependency information“? I would say, these
are library dependencies or other dependencies neccessary for the
executables in the package to startup.

jed and xjed need jed-common and libslang2 to startup, but jed-common do
not need jed or xjed.

> I read this as
>   
>   If A is broken as long as B is installed, A should declare a Conflict.

I like to look what other packages do or what would I do if I transfer
the problem to other packages.

firefox, e.g., does not conflict with old extrentions or plugins they do
not support the new firefox API.

Should libssl conflict with all packages they do not work with a new API?

I think the problem is the package name jed (or xjed) do not reflect the
slang library version. Else jed-extra << 1 would depend on jed1 and a
jed-extra >= 1 would depend on jed2. But this naming scheme is not given
and as long as they do not create problems for jed we should not conflict
with a package. Maybe, some mode of jed-extra 0.1.8 is usable with jed
and this is enough for a user.

I would really see the conflict and depends fields as informations for
the package level and library level not the usability level.

> and how should I understand Policy 7.3
> 
>   Conflicts entry should almost never have an "earlier than" version
>   clause. This would prevent dpkg from upgrading or installing the
>   package which declared such a conflict until the upgrade or removal of
>   the conflicted-with package had been completed. 

This paragraph I did not understood, too.

> If we remove the Conflict with jed-extra (<= 1.0-1), can we upload jed
> 0.99.18 to testing without waitig for jed-extra 2.2 ?

AFAIK, yes.

Have a nice weekend, Jörg.
-- 
Dein Gesicht wird dir geschenkt. Lächeln musst du selber! (Inga Hermann)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20060609/80126f26/attachment.pgp


More information about the Pkg-jed-devel mailing list