[Pkg-electronics-devel] RFS: NEW: geda-gaf 1.6.0-1

Peter Clifton pcjc2 at cam.ac.uk
Fri Dec 4 14:20:34 UTC 2009


On Fri, 2009-12-04 at 14:21 +0200, أحمد المحمودي wrote:
> On Fri, Dec 04, 2009 at 12:02:51PM +0000, Peter Clifton wrote:
> > On Fri, 2009-12-04 at 09:17 +0200, أحمد المحمودي wrote:
> > 
> > >     + Removed libgeda33 from Conflicts of geda-symbols, as this was
> > >       never needed.
> > 
> > I think we need something to show that the new geda-symbols package in
> > this release, will not work with old libgeda libraries. That conflicts
> > was probably added when the shipped symbols changed so they would only
> > work with latest libgeda.
> > 
> > We have that situation again with this release.. new geda-symbols ought
> > to conflict with old libgeda I think. (We'll let you know when this is
> > the case for future releases)
> 
> In that case I would rather add a:
> Depends: libgeda38

I'm not sure whether that is equivalent.

It suggests that geda-symbols-1.6.0 requires libgeda38 (which it doesn't
in the strictest sense). Symbols are just data-files, and "could" be
installed on their own (e.g. by someone wanting to poke inside them).

Requiring libgeda38 doesn't mean that another version of libgeda isn't
installed as well. What is really missing, is that it doesn't convey
that any currently installed libgeda<38, would be broken (would not
load) the new symbols.

I can't imagine putting the relationship the other way (and have libgeda
require the particular symbols version). libgeda doesn't require the
symbols to work, and in any case, we can't know in advance which symbols
releases will be forward compatible with a particular libgeda version.

I guess in general, we could be pessimistic, and assume that each new
geda major version (1.6.x, 1.8.x) breaks forward compat. That then
implicitly forces the fact that libgeda(n) and libgeda(n+1) can't be
co-installed. 

Hamish?





More information about the Pkg-electronics-devel mailing list