[fink-core] Packaging design issues.

[Robert M.Z. <ti...@ti...>]

This mail comes about from my bug reports (976319 and 976299).  The 
issue with these bugs is similar, but a little different.  Please note 
that I am not on the fink-core list, so please cc me in this 
discussion.  I am not trying to flame, I'm trying to add input to make 
the product better.

Because this is the type of issue that affects several packages, I'm 
going to speak only hypothetically.  The ssl packages are a good 
example to use in this, but certainly not the only place.

A piece of software, called 'A' is included in Fink as a package.  
Assume that A can be compiled with ssl support.  In general, this would 
mean that there would be at least two packages in fink: 'A' and 'A-ssl' 
  These are different pieces of software because one has ssl support and 
the other doesn't.  (I'm not going to argue against the crypto branch 
here.)  That is the only difference between 'A' and 'A-ssl'.  SSL 
support.  This means that 'A-ssl' is really a superset of 'A'.

A second piece of software 'B' is included in Fink as a package.  'B' 
depends upon libraries from 'A'.  There are few ways in which this can 
done.

1.) 'B' requires 'A' or 'A-ssl'
2.) 'A-ssl' provides 'A' and 'B' requires 'A'
3.) 'A' and 'A-ssl' both provide 'A-base' (or something like that) and 
'B' requires 'A-base'

The first method appears to be the current philosophy used.  This puts 
the burden upon the maintainer of 'B'.  Because there may be several 
packages that depend upon 'A' that are like 'B', there are several 
potential entry points for error, 'A' variants times 'B' packages and 
variants for every 'B' package.  This is reduced in either methods 1 or 
2 to the number of 'A' variants that there are.

I am not going to claim that this scenario fits all packages in fink, 
but I think that it does fit several of them, particularly when there 
is a package with ssl and one without.

[NOTE: further investigation of the following issue reveals that there 
is a bug in Xemacs here, not the GNU emacs package.  GNU Emacs provides 
'emacsen' but Xemacs doesn't.]
For packages that do not fit in the SSL model, there is the emacs 
packages.  Xemacs and GNU Emacs are different, but they are very 
similar.  Both GNU Emacs and should provide a common requirement 
because of their similarities and dependent packages should /generally/ 
depend upon that common requirement. I say generally because there are 
going to be instances such as a piece of lisp working only with GNU 
Emacs and not Xemacs, or vice versa. They currently don't.

There is a similar issue with different versions of the same software 
that exist due to loss of backwards compatibility or something similar 
but it is enough more complicated that I haven't formulated a way to 
work around that.  Simply using the version numbers does not 
immediately appear to be adequate (though you might be able to hold on 
to the older version), nor do the methods mentioned above.  I would 
like to think that this is not the normal circumstance though.

Again, it is not my intent to flame or just cause disruption.  The idea 
is to make the product better.  Regardless of what philosophy is 
adopted, I think better QA is something that needs to be implemented or 
enforced (note the xemacs issue above).  This mail is meant to address 
reducing the potential number of QA issues.  There are several similar 
(Python23 is installed, but when trying to install subversion it asks 
which python I want....oops (yes I know bug report it, but I'm waiting 
to see where this discussion goes first.))


Regards,


Robert M. Zigweid
-- 
Robert M. Zigweid                   ti...@ti...
                                     http://www.tigransoft.org