state of jed-extra

G. Milde g.milde at web.de
Fri Jun 9 09:04:32 UTC 2006


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?

Policy 7.2:

   The Depends field should be used if the depended-on package is
   required for the depending package to provide a significant amount of
   functionality. 

While jed-common and jed-extra will not do any harm without jed|xjed
(i.e. they are mostly useless but not broken), they depend on jed|xjed for a
"significant amount of functionality".

Maybe better Recommend:

   The Recommends field should list packages that would be found together
   with this one in all but unusual installations.

this would leave the possibility to use e.g. jed-extra with a locally
installed jed.


> > While dpkg doesnot resolve dependencies automagically, 
... 
> >  * it is still the tool of choice for installing individually downloaded
> >    packages 
> ... for those who know how to use it.

Thanks for your hints, now I see what has been going on.


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.


I read this as
  
  If A is broken as long as B is installed, A should declare a Conflict.
  
However, how should one solve the case:

  B will become broken if A is installed
  
for a new version of A?    

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. 

? Is an "earlier than" version clause something like

  Conflict: B (<= nn)
  
or

  Conflict: B (=> nn)

?


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 ?


Sincerely

Günter






More information about the Pkg-jed-devel mailing list