tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Discussion about pkgsrc dependencies and default build options
On Fri, May 13, 2022 at 07:52:46AM +0000, nia wrote:
> > > There was a decision some time back to explicitly not do that. The
> > > primary motivator, AFAICR, was that installing extension modules from
> > > pkgsrc makes a huge mess. That and it's so small it doesn't really
> > > matter.
> >
> > Thanks for pointing that out. I dropped a note in the
> > lang/lua53/Mekefile.
>
> I'm not sure it's much of a problem actually. You can use
> extensions from pkgsrc with base system lua easily by
> modifying Lua's extension path.
I forget the details because it's been a long time since this last
came up.
My recollection also is that at one point FreeBSD imported Python into
their base, and then later got rid of it, at least in part and maybe
largely because of such issues, and that experience informed our
decision. But that too was a long time back, I think.
Objectively it seems like it wouldn't need to be a problem, but it
depends on the language's own extensions infrastructure and how well
it's able to cope with multiple sources of installed extensions. I could
imagine that Lua is simple enough to work where Python is more
elaborate (but not elaborate enough) and gets into trouble.
There's still the unanswered question of how base knows where the
right packages installation is.
Probably we (or Someone(TM)) should rake all this up, sort it out, and
write a single coherent explanation of what the known problems are.
If nothing else, that would be a useful thing to be able to point
upstreams at.
> However, from my perspective, having unversioned Lua would make
> a huge mess. This is not like Python where applications generally
> always support the last couple of versions. They generally want a
> specific, fixed version. That's why we have so many Luas.
It would need to be a builtin for a specific version. That is probably
doable, maybe with some strengthening of the handling for interpreter
paths. Assuming our builtin stuff will work at all for interpreters as
well as libraries, which I'm not clear on.
(One of these days we really ought to take up an organized scheme for
installing shadow packages for builtins. There are any number of
reasons to, but it's a huge project.)
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index