On Fri, Oct 08, 2004 at 01:37:30PM +0200, Pavel Cahyna wrote:
> > On Fri, Oct 08, 2004 at 08:29:42AM +0200, Pavel Cahyna wrote:
> > > I looked briefly at the documentation and it seemed like a complicated
> > > solution to a simple problem. It is designed to handle packages which are
> > > not supposed to be installed together. But different versions of dynamic
> > > libraries are designed to be installed together, that's why they have
> > > version number embedded in filename, so they don't need to have each its
> > > own directory.
> > 
> > ELF libraries have a combination of version numbers - major, minor,
> > and some have what the docs term "teeny".  What is actually linked in
> > at run-time in the ELF case is the libwibble.so.1 symbolic link - i.e.
> > the major one.
> > (...)
> > How do you propose to provide many instances of a library with the
> > same major number in the same directory?
> 
> I don't propose anything like this. Why should there be many instances of
> a library with same major number? If the major number is the same, they
> are compatible, so one instance should be enough.

So your stance has moved to that of "it doesn't matter what minor version
of the shared library is used, because it's compatible through the major
version branded into the SONAME in the binary"?

> > I'm disappointed that you think that package views are complicated. 
> > To me, they're simple, perhaps ugly, but very functional, and very
> > little extra overhead in terms of user intervention, space, speed, and
> > installation overhead, but I admit that my outlook isn't exactly
> > unbiased.
> 
> I think that they are too complicated for the problem of multiple versions
> of shared libraries. It is a question if they are usable as a more general
> method for having multiple versions of a single package, but for shared
> libraries it seems to be an overkill. I also think that concerns raised by
> Greg A. Woods in
> http://mail-index.netbsd.org/tech-pkg/2003/08/21/0049.html may be valid.

I am absolutely distraught that Greg's views are different from my own.
 
> Also your paper talks about "dynamic PLIST". Does this mean that the list
> of package's content will be automaticaly generated when a package is
> built? That would be really wrong, IMHO. I encountered several times that
> some of the files in the PLIST were not built or were installed elsewhere.
> It always meant that there was an actual problem and such packages never
> worked properly. If the PLIST is static, such problems can be detected
> more easily. (I would prefer to be warned more loudly about this problem -
> for example by having a mail to root be sent when this happens.) If the
> PLIST was dynamically generated, I would never know that something is
> wrong.

PLISTs can either by dynamic or static, depending on the contents of
the PLIST_TYPE definition.  It takes the values "dynamic", and ... 
err ...  "static". If you don't like dynamic PLISTs, that's fine,
you don't have to use them.
 
Regards,
Alistair