On Sat, Jun 4, 2011 at 10:06 AM, Allan McRae <firstname.lastname@example.org> wrote:
> The current implementation seems fine and I would say ready to merge. *I
> will probably make some minor changes on the merge, but mostly cosmetic
> However, I have one final query: *Do we need some way to disable this?
> Is it possible that a package will have a name in the form "foo.so" that
> would cause an issue here? *Note that is a perfectly valid package name. *I
> find such a package name unlikely but think about if support for other
> library types gets added in the future then we could get potential
> conflicts. *OSX and Windows library names are unlikely, but foo.library is a
> shared library in Amiga OS and a more reasonable pkgname...
> So options are:
> 1) we ignore that possibility until a real world case shows up
> 2) we provide a way to disable this feature
> 3) we move to using libprovides=() and libdepends=() arrays
> I am happy following #1 for the current time as I think I am probably being
> too wary here, but would like opinions from others on this.
1 is fine to me at the moment, only because I think we don't need to
worry yet and an easy way to disable this is add an options array
value of !libdepends or something like that. Either way the decisions
we are making now don't seem to be prohibiting such an addition in the
> Finally, none of this has been documented in the man pages. *Even some draft
> documentation that can be edited would be very helpful.
Agreed, without documentation this can't really get merged and be
useful to most people.