Needs debianization #221
Comments
Original comment by
|
|
ubuntu 14.04 doesn't show anything, by the way. Has anybody made a sort of vaguely official package for debian/ubuntu? |
|
Well, packaging files into debs is one thing, but maintaining packages requires some amount of bureaucracy. There are PPAs for Ubuntu, but it's much harder to get your package into Debian's repositories. I use Debian so at least I can try making a source DEB package for Chibi. |
|
The funny thing is I used to be a Debian developer (for GNU Smalltalk). |
is bound in only one of the environments. This is necessary in the case where a library uses an unbound keyword (e.g. "with" in (chibi loop)), but you want to use it along with a binding for the keyword (e.g. "with" in (chibi show)). The alternative to work with the current logic is to always require such keywords to be bound, in this case to add a dummy "with" auxiliary syntax binding to (chibi loop), however this doesn't seem any safer than the new logic, and the whole point of the feature is convenience. Fixes issue #221.
|
Ignore that commit, it was meant for issue #246. |
|
Looked at packaging this for Debian. You may hate GNU autotools, but they do make it easier to package: getting libraries into the right places like /usr/lib/x86_64-linux-gnu/ and whatnot. Just saying... |
|
You can get packacking right without Autotools as well, the Makefile just has to support all the conventional variables like |
|
That would be nice, wouldn't it? But search the below for I can try to tweak the |
|
A few other packaging-related questions. I hope you don't mind my asking them here. But I hope rather than answering them inline, someone can put the answers in the documentation, like
Sorry for the big blat of questions; I could try to figure them out, but you probably know offhand. And I might well get some wrong. |
|
in case you still need someone with some interest in chibi but also debian upload permissions: please let me know |
|
@robertlemmen I'm a DD but happy to leave this to you, or to co-maintain, whatever. |
|
@barak, I think that packaging breakdown looks good, although probably chibi-scheme instead of just chibi. You probably want to put all scheme libraries together with libchibi-scheme0, but could arguably put any that don't use the FFI in chibi-scheme-common (otherwise no need for a common package). install.h will be generated with the matching install paths used by the makefile. libchibi-scheme.a already has a make target. Did you try just packaging this? DESTDIR, PREFIX, LIBDIR etc. are already supported. |
|
@barak nah, if you got it covered then that is perfect :) I just wasn't sure from the email thread whether you had the maintainer tick or not |
|
@barak If the position is still open I'd like to give it a shot. |
|
@ilammy Please, go for it. Let me know if there's anything I can do to help. @ashinn Yes, there is a prelim packaging in github.com/barak/chibi-scheme branch debian, the build does not use the appropriate paths. DESTDIR is correct (upper case) but libdir, prefix, etc should be lower case. Not sure if that would fix things, have not checked, might still need to add some code to pass them through properly. |
|
Here's a status update. The packaging code may be found in my fork: ilammy/chibi-scheme @ debian/sid. Building instructions
I've managed to get the paths right with some really vile trickery (pretending to have a The This builds a single package with full file set and it works when installed (yay!). Now I'm going to work on the package split and, well, all that metadata that needs to be filled in: licenses, dependencies, descriptions, etc. P.S. It turned out that if you actually sit down and read the 'Debian New Maintainers' Guide' then all these spells start making sense :) |
|
Wow, that is truly vile! I am lost in admiration. I used the |
|
Very nice @ilammy ! Most of those patches look good to merge directly to upstream. |
|
Okay, I'm going to try to merge your efforts with mine and upload to Debian. |
|
So... this is not over yet! After some on-and-off efforts I've updated the packaging:
I'm still learning the ropes, but I guess it's close to not being embarrassing to post this to mentors.debian.net. I hope I'll get to submit non-Debian-specific fixes as pull requests soon. In the mean time I've had fun hunting compatibility issues between Ubuntu releases which resulted into this PPA with packages for current Ubuntu series: sudo add-apt-repository ppa:ilammy/chibi-scheme
sudo apt update
sudo apt install chibi-scheme Please test 🙏 |
|
It would be nice to update this to 0.9.1. |
|
I've updated the packaging lately to 0.9.1, it seems to be working well, including images! |
|
So, what's the story? Should I have another look with an eye towards pushing it into Debian? Or does somebody else have that under control... |
|
It sounds like @ilammy has PPAs but is not working on getting this into official Debian? |
|
Okay, had a look. First, I'm very happy to upload chibi-scheme into Debian. But, the
In all seriousness, these are the sorts of issues that |
|
Am Do., 27. Aug. 2020 um 12:05 Uhr schrieb Barak A. Pearlmutter <
notifications@github.com>:
In all seriousness, these are the sorts of issues that autotools is
absolutely fantastic at getting right, if you just use its approved
mechanisms and go with its flow. Of course that whole system is horrible in
a zillion ways. But it does allow short configure.ac and Makefile.am
files, and then it sweats all the details of getting all the installation
paths right in a portable way, of dealing with executables that are
generated and also used at build time and need to use shared libraries that
have been built but not installed yet, etc. These issues are autotools's
bread and butter, and the current system is gradually reinventing a lumpy
wheel.
+1000
If only Alex could be persuaded, I would volunteer to help autotoolizing
the build system (*).
Marc
…--
(*) The first step would be to remove the existing configure script, which
seems to be oblivious of the fact that Automake Makefile's are still
basically Makefiles. :)
|
|
To sum it up: the current system is kinda WIP, I'm glad to get feedback, and will work on improving it.
It's quite likely. The fakechroot is recent, experimental addition by me for packaging. It seemed to work on my machine, but evidently it's still got issues. I wanted to make sure that the images generated by Chibi during the installation process do not include incorrect paths in them. Currently, they remember DESTDIR with Debian temporary directory in the source code information, so whenever Chibi is using images and prints a stack trace, the source lines lead to the temporary DESTDIR, not actual source code installed. I was not able to quickly identify the proper way to resolve this, so using fakechroot was a quick hack.
Yeah, I'll agree here. I'm leaving it there as initially I was not able to get debhelper to pass proper paths in
This is more of an intentional decision to keep libraries managed by As for the whole Autotools debacle, I personally absolute love it as a user when it works. However, I don't have much experience with maintaining software that uses it, so I have no opinion here. The current project that I'm involved with also uses bare Makefiles, without Autotools, and could probably benefit from it as it also has lots of platform detection code... Though, well, with Chibi I guess the code is portable enough for it to be okay to use plain Makefiles. I think that if |
|
Am Do., 27. Aug. 2020 um 12:59 Uhr schrieb Alexei Lozovsky <
notifications@github.com>:
As for the whole Autotools debacle, I personally absolute love it *as a
user* when it works. However, I don't have much experience with
maintaining software that uses it, so I have no opinion here. The current
project that I'm involved with also uses bare Makefiles, without Autotools,
and could probably benefit from it as it also has lots of platform
detection code...
Though, well, with Chibi I guess the code is portable enough for it to be
okay to use plain Makefiles. I think that if debhelper could pass
debianized paths via conventional variables, that should be enough for
Chibi to build fine, as there is very little code that actually needs to
know the platform, like which functions are available, etc. – all that
other stuff checked by Autotools besides the installation paths.
It's mostly the Automake functionality that could help, namely providing
standard targets, out of source tree builds, etc. There are a few ifdefs in
the code, which could possibly be rewritten using standard Autoconf checks.
|
|
Wow: rough consensus! Re |
|
Autotools help nothing here - changing the variable names is a few lines of code. It would also require a full rewrite of the build configuration and bring in a whole host of complexity and all new problems. That's one of the worst solutions I've ever heard of for a bug, even discounting my hatred of autotools. I've pushed a new version of the Makefile allowing the "standard" GNU names. Autotools will never be an option, please stop suggesting it. |
That's like saying that HipHop for PHP is still basically C++. |
|
Am Do., 27. Aug. 2020 um 16:13 Uhr schrieb Alex Shinn <
notifications@github.com>:
(*) The first step would be to remove the existing configure script, which
seems to be oblivious of the fact that Automake Makefile's are still
basically Makefiles. :)
That's like saying that HipHop for PHP is still basically C++.
I hope it is a good sign that I had to look up what HipHop is. :)
Automake copies your Makefile.am mostly verbatim (and just adds some rules
for the standard targets). So it is more like what CPP is for C. Call it a
declarative Prolog preprocessor. :)
|
|
Hmm, how about CMake. Current Nowadays, many packaging systems treat CMake as first-class citizen. Obvious, major downside of this is: we have to maintain two distinct build system, much more seriously. (un)fortunately, it is not special though. e.g.) libsdl( https://www.libsdl.org/ ) and libuv( https://github.com/libuv/libuv ) have both CMake and autotools. I think we can live with it since now we have CI. |
|
Well, the problem is, I never managed to get This is how barren the invocation line looks for me with And here are all the goodies that only Autoconf gets: Anyhow! The best approach that I came up with so far is to hardcode the paths a little bit differently: # Manually implement multiarch support here since debhelper seems to pass
# this information in a proper form only to the Autoconf build system.
# When using "--buildsystem=make", no multiarch support is added.
# Chibi does not support Autoconf so we have to fix up the paths here.
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
EXTRA_ARGS += PREFIX="/usr"
EXTRA_ARGS += LIBDIR="/usr/lib/$(DEB_HOST_MULTIARCH)"
EXTRA_ARGS += SNOWPREFIX="/usr/local"
EXTRA_ARGS += SNOWLIBDIR="/usr/local/lib/$(DEB_HOST_MULTIARCH)"And drop all the trickery with It's not nice since if Debian decides that the correct |
|
Regarding snow-chibi paths. chibi-scheme already looks into multiple paths for installed modules. The packaging makes it look into the following paths:
It uses the first library found while following this order. However, it's still an open question of where snow-chibi should install its stuff. I'd like to have an option of user-local installation, but this is definitely out of scope for packaging. It sound more like a new feature for snow-chibi. I'd guess that later snow-chibi could be taught some But that should come later, IMO. Right now it can only install stuff locally, system-wide. |
|
No comment on the fakechoot issue, other then I have managed to reproduce it with |
|
I was building debian packages before dh even existed, and it wasn't that hard back then. Another example of how dangerous all of these extra layers of abstraction are. Let me take a look. |
|
The following This is using the newer lowercase We could also fill in the remaining targets listed in https://www.debian.org/doc/manuals/maint-guide/dreq.en.html and not use dh at all. |
|
I think it's a |
|
Alrighty... After several more attempts to fix this, I have thrown away Now if you do this (with images installed): then stack traces are actually correct, not leading into some Other cleanups include removal of redundant patches, and some copyright metadata update. The package should be at least buildable now. |
|
@barak wrote:
@weinholt since you're a Debian developer as well, do you happen to know about this? |
Nope. I just do what everyone does when debhelper doesn't help: add an override. It's fine. |
|
@weinholt Okay, I made a pass over the @ilammy Barring objections, I'll change |
|
That reminds me: How difficult is it to create a custom APT package repository? It would be nice to run stable Debian on a server but add a line to |
|
We already have the build scripts at https://github.com/scheme-containers, would just need to add the Debian magic. |
|
@lassik The "Debian magic" is hours and hours of manual work. For example, I spent 12 hours yesterday to get the Debian packaging of Chez Scheme 9.5.4 in good order. Chez is an extreme case, but still. Basing Debian packages on the work we did for the Docker containers is unfortunately not realistic. (I have some ideas though; will send you an email.) |
|
@lassik It's reasonably straightforward to create something Debian users can add to There's been talk of making a Debian version of Ubuntu PPAs, but it hasn't happened yet. You can also use Ubuntu PPAs directly with Debian, albeit sometimes with some issues. |
|
|
So I guess this will go into bullseye? Anything else needed before we close the ticket? |
|
No, I think that's that. Let me know if there are any issues with it. |
|
Thanks! |
Original issue reported on code.google.com by
pjimen...@gmail.comon 27 May 2014 at 5:58The text was updated successfully, but these errors were encountered: