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

[أحمد المحمودي]

On Fri, Dec 04, 2009 at 12:37:26PM +0000, Peter Clifton wrote:
> 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?
---end quoted text---

I thought of it for a while, here's what I see:

1. It is not right to add libgeda33 to Conflicts of geda-symbols, 
because they do not actually conflict (meaning that there are no common 
files between them)

2. As far as I understand, geda-symbols is not used by itself, it is 
used by some other geda-* tool (such as gschem or so), since geda-* 
packages depend on libgeda38, hence I don't see that there will be a 
problem. Meaning that since a geda-* 1.6.0 package depends on:
geda-symbols (>= 1:1.5.1), geda-symbols (<< 1:1.7.0~) and also 
libgeda38, hence, practically both of geda-symbols 1.6.0 & libgeda38 
will be actually pulled by apt-get/aptitude to get this geda-* package. 
I hope I was able to make myself clear.

-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7 (@ subkeys.pgp.net)
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7