@galdor
/not// (eg the standard has in-package which makes package-name the current package)
@josemanuel
I could see my way to supporting this as a way to download packages via ports or ebuilds (or lispi's nix), which is still my favourite solution. I think system distribution needs to be separate to ASDF.
@louis @lispi314
@screwtape To me, ASDF should be used similarly to composer.json and composer.lock files for PHP, as a way to define systems and its dependencies. Of course, ASDF already does that, but I miss certain functionality, like declaring which versions of which dependencies work best, or at all, with one's own system (I hope I'm using the right terminology this time) and more metadata in order to help with discoverability on the distribution platform. Also diferentiating between dependencies in development, like test suites, and dependencies in production.
Right now (please correct me if I'm wrong), ASDF uses these metadata mostly as an aid to load systems, but not in the way I'm proposing, as a way of identifying packages and differentiating between versions.
A different script could then download, install and maybe even load those systems.
@galdor@emacs.ch @louis@emacs.ch @lispi314
@josemanuel
ASDF is fairly deep, such as defining operations like the typical 'TEST-OP or custom ones. However it only allows specifying minimum versions of packages, not pinning versions. Because there is so much to ASDF, and it packages with UIOP, I think adding the burden of package distribution has to be placed somewhere else (and my intuition is that package distribution on an operating system is the concern of that operating system (distribution))
@galdor @louis @lispi314
@screwtape
> the burden of package distribution has to be placed somewhere else
That's what I said at the beginning. System distribution should be derived to repositories that all work according to a standard API. That way, we could have a decentralised way to download systems and get info on them.
> package distribution on an operating system is the concern of that operating system
I'm not sure I'm understanding this right. Are you suggesting that CL systems be packaged and distributed by OS maintainers?
@galdor@emacs.ch @louis@emacs.ch @lispi314
@lispi314 @josemanuel
oh, I thought you meant it should be packaged with asdf.
Yeah, my thought was that packagers could package package packages similar to the practice at the gentoo lisp overlay
https://www.cliki.net/Gentoo
since I think the problem of how to get lisp packages onto the OS or linux distribution is a problem of the OS or linux distribution.
openbsd is a bit of a special case, because openbsd has special security concerns in it (most mounts not wxallowed, pledge, ..
@galdor @louis
@screwtape @josemanuel @galdor @louis Or does that security layer interact with general purpose libraries?
@lispi314 @josemanuel @galdor @louis
It's not just one thing and yes.
@screwtape @josemanuel @galdor @louis Ah, meant to write that as "how does" not "or".
@lispi314
tritely, what if a library wanted wxallowed.
@josemanuel @galdor @louis
@screwtape @josemanuel @galdor @louis Well, more like can you write a program using that library which wants that or is it transitively forbidden?
@lispi314
I would want to look at some openbsd patches to well known C/C++ libraries before strengthening my opinion.
@josemanuel @galdor @louis
@josemanuel @screwtape @galdor @louis Generally that seems sensible.
Content-addressing of various sorts could of course be used as the underlying source for said packages.
But generally on a given operating system have only a few main ways to manage software & libraries is preferable and generally more reliable.