> 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.

 
> 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.

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.

(BTW I also don't like that the install is done as root. That way,
packages can install files elsewhere than they should, overwriting any
other files, etc. I would prefer building a binary package as non-root
user, root should only execute the pkg_add command. Sorry for the
off-topic...)

Thanks for your interest.

Bye	Pavel