For previous versions of ASDF, Faré has been providing a debian package, cl-asdf.
I'd like a volunteer to take over the packaging process.
The more I mess with this, the less I feel like I know what I'm doing. I haven't *maintained* (as opposed to used) a Linux box for about 5 years, and when I did, I used an RPM-based distro, instead of a .deb-based one. For that matter, this is not dogfood that I plan on consuming.
So.....
1. Is anyone else willing to take over the packaging? This should be relatively minimal amount of work, really just running the build scripts, uploading the packages, and yelling at me when the Changelog is badly formatted, etc.
2. If the answer to #1 is "no," how bad is that, anyway? Does anyone actually use ASDF from cl-asdf instead of getting it bundled from their implementation or installing from source? Maybe this package could simply go away?
Cheers, r
On Wed, May 14, 2014 at 10:53 PM, Robert P. Goldman rpgoldman@sift.info wrote:
For previous versions of ASDF, Faré has been providing a debian package, cl-asdf.
I'd like a volunteer to take over the packaging process.
The more I mess with this, the less I feel like I know what I'm doing. I haven't *maintained* (as opposed to used) a Linux box for about 5 years, and when I did, I used an RPM-based distro, instead of a .deb-based one. For that matter, this is not dogfood that I plan on consuming.
So.....
- Is anyone else willing to take over the packaging? This should be
relatively minimal amount of work, really just running the build scripts, uploading the packages, and yelling at me when the Changelog is badly formatted, etc.
I'm Cc'ing the debian common lisp team. Maybe someone there can take over.
- If the answer to #1 is "no," how bad is that, anyway? Does anyone
actually use ASDF from cl-asdf instead of getting it bundled from their implementation or installing from source? Maybe this package could simply go away?
cl-asdf used to be very important back in the bad old days of ASDF 1, when implementations didn't provide it (except sbcl, mostly), and configuration was its own hell that common-lisp-controller was trying to solve.
These days, most implementations (at least all those in debian?) provide ASDF, and thanks to ASDF 2, c-l-c doesn't have to anything to do anymore. It used to try to manage a system cache of fasls, but that was disabled after it was found to be a big security risk. The only correct way to do it would be with a daemon, that compiles from clean debian-managed systems using debian-managed implementations only, in a new process with a clean environment, etc. Since no one is interested in actually writing that, I would just retire c-l-c instead. cl-asdf itself is marginally useful, for cases when you need a more recent asdf than the implementation provides, but it's not as big a deal as it used to be.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He wa'n't no common dog, he wa'n't no mongrel; he was a composite. A composite dog is a dog that is made up of all the valuable qualities that's in the dog breed — kind of a syndicate; and a mongrel is made up of all riffraff that's left over. — Mark Twain
Faré wrote:
- If the answer to #1 is "no," how bad is that, anyway? Does anyone
actually use ASDF from cl-asdf instead of getting it bundled from their implementation or installing from source? Maybe this package could simply go away?
cl-asdf used to be very important back in the bad old days of ASDF 1, when implementations didn't provide it (except sbcl, mostly), and configuration was its own hell that common-lisp-controller was trying to solve.
These days, most implementations (at least all those in debian?) provide ASDF, and thanks to ASDF 2, c-l-c doesn't have to anything to do anymore. It used to try to manage a system cache of fasls, but that was disabled after it was found to be a big security risk. The only correct way to do it would be with a daemon, that compiles from clean debian-managed systems using debian-managed implementations only, in a new process with a clean environment, etc. Since no one is interested in actually writing that, I would just retire c-l-c instead. cl-asdf itself is marginally useful, for cases when you need a more recent asdf than the implementation provides, but it's not as big a deal as it used to be.
I'm inclined to think that figuring out how to load ASDF from the cl-asdf debian package to override an ASDF that has been packaged with your implementation is no easier than doing so from cl.net. Indeed, it may actually be more complicated, since you have to figure out how to load from where the debian package puts asdf, instead of where you have put it in your own user directory.
So I suggest we just drop the cl-asdf package: the cost of maintaining it cannot be justified by the benefit it provides to the community.
That said, if the Debian community disagrees with me, I don't mind maintaining the debian packaging in the ASDF git repository. I just don't have the time and energy to take it that final step of maintaining an appropriate Debian build environment, building the package, and shipping it.
Best, R
I'm inclined to think that figuring out how to load ASDF from the cl-asdf debian package to override an ASDF that has been packaged with your implementation is no easier than doing so from cl.net. Indeed, it may actually be more complicated, since you have to figure out how to load from where the debian package puts asdf, instead of where you have put it in your own user directory.
So I suggest we just drop the cl-asdf package: the cost of maintaining it cannot be justified by the benefit it provides to the community.
That said, if the Debian community disagrees with me, I don't mind maintaining the debian packaging in the ASDF git repository. I just don't have the time and energy to take it that final step of maintaining an appropriate Debian build environment, building the package, and shipping it.
The cl-asdf package is useful for 1- use by CL implementation packages themselves, at compile-time, when they don't otherwise come with a recent enough version of ASDF (if at all). i.e. if someone wanted to update the package for GCL, or create one for SCL, etc. 2- for use by libraries and applications that require a version that is more recent than otherwise provided by CL implementation packages.
So I'd say that going forward, this could be done easily by whoever needs it for his own debian CL packages.
That said, I can do the asdf debian package one last time for 3.1.2. I've experimented a bit and come up with a better recipe. Apparently the trick to avoid dealing with complications is to work in a branch where the only changes since the upstream release tag are in the debian/ directory. If you let me do it, I'll do it in the release branch. I updated the bin/asdf-builder script to do the release (moving code from the Makefile and making it better — scripting is SO much better in Lisp). Of course, the script as exists in the release branch is insufficient, and since it does a git clean -xfd we need to extract it from master under another name everytime.
So: I committed some debian-only changes in my release branch (not pushed — but I can do it if you approve, and even upload), and ran: git show master:bin/asdf-builder > bin/x && chmod a+x bin/x && ./bin/x debian-package and it looks like it worked. I can push all that if you want, or show you how to do it. It's a matter of git checkout release ; git show master:debian/changelog > debian/changelog ; edit debian/changelog
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Women can form a friendship with a man very well; but to preserve it — to that end a slight physical antipathy must probably help. — Nietzsche, HAH
-
Faré -
Robert P. Goldman