$ apt info crystal -a
Maintainer: David Suárez <email@example.com>
Installed-Size: 19.8 MB
Depends: pkg-config, libc6 (>= 2.34), libevent-2.1-7 (>= 2.1.8-stable), libgc1 (>= 1:7.4.2), libgcc-s1 (>= 3.3), libllvm14, libpcre2-8-0 (>= 10.22), libstdc++6 (>= 11), libgc-dev
Suggests: crystal-doc, crystal-samples
Download-Size: 3,614 kB
APT-Sources: http://deb.debian.org/debian testing/main amd64 Packages
Description: compiler of the Crystal object-oriented programming language
The Crystal's language syntax is inspired by Ruby, the language is statically
type-checked but does not require that the type of variables or method
arguments be specified.
The language has the following goals: (1) have the same syntax as Ruby, or at
least as similar as possible; (2) statically type-checked but without having
to specify the type of variables or method arguments; (3) be able to call C
code by writing bindings to it in Crystal; (4) have compile-time evaluation
and generation of code, to avoid boilerplate code; (5) compile to efficient
Maintainer: Crystal Team <firstname.lastname@example.org>
Installed-Size: 133 MB
Depends: gcc, pkg-config, libpcre3-dev, libpcre2-dev, libevent-dev
Recommends: libssl-dev, libz-dev, libxml2-dev, libgmp-dev, libyaml-dev
Download-Size: 31.8 MB
APT-Sources: http://download.opensuse.org/repositories/devel:languages:crystal/Debian_Unstable Packages
Description: Crystal is a general-purpose, object-oriented programming language.
With syntax inspired by Ruby, it is a compiled language with static type-checking,
serving both, humans and computers.
I submitted a bug in the debian issue tracker. It would be good if Crystal is properly shipped out-of-the-box in debian-based systems. I’ll see how much engagement I get from the maintainer to drive this to completion…
Comment: removed because there are distributed without the original source code
But as far as I can see, all the packages in vendor are MIT licensed if going to the original source. Shouldn’t it just be a matter of the core team committing the original LICENCE file from each project?
the package is distributed under the MIT license but our users will
not be able to make use of the freedoms this license is granting
them (specifically, modify the files we ship) using just the tools
in Debian main, instead they need tools outside of Debian. It is
violating the spirit of the DFSG if we are shipping files that our
users are unable to modify.
As octicons could not be used as a dependency and our rules are that we do not like to use precompiled or vendored software inside packages, the playground cannot be compiled until octicons will enter again the Debian archive.
OK, sometimes Debian is giving me a headache.
So the Crystal playground is disabled because you can’t modify the font file it uses with the tools available in Debian…
I do appreciate that the Debian maintainer of the docker package does the work of splitting up the package and dynamically linking it, rather than just statically linking everything in as they do in the official package.
But crystal is using v3.5 of octicons, which is from 2016… The newest versions doesn’t even use font files anymore, but just uses the SVG files directly. So the chance of a variant of the package that Crystal can use, getting in Debian is, as you say, practically zero.
Which is mightily unfortunate as the playground is very helpful for the new user.
So, for the sake of the argument, if someone took it upon themselves to grab the SVG of the few icons the playground uses, put them in a directory with a note saying where they were obtained from and a copy of the license, replaced the usage of said icons to be inline SVG rather than CSS and fonts, and removed the octicons folder… Could that revive the playground in the Debian package?
I’m far from any lawyer, but I believe that this should be in accordance with the octicons license, and SVG is certainly editable with Debian tools. And until someone packages the SVG files of octicons one can make the argument that it’s far more efficient to include the few icons used rather than having to package the whole set.
The main point is that we can simply redistribute a compiled form of the font:
distributing compiled files, does not gives the security that are 100% the original source.
doing it will break the liberty of the user to do what he wants to do with the fonts.
You solution on simply copy and paste the fonts, im not an expert lawyer too, could work if the application states clearly and includes the original copyright and a copy of the original license, as the MIT license elaborates:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
But really, including vendoring software inside another software is always a pain in the ass for package distribution. And for end users too. Theres not any gain If every app has it owns copy of his third dependencies.
I follow the logic, I just think it’s a tad pedantic when applied to an icon font. Even if you can “recompile” octicons, you can still replace it with a font of handdrawn icons without loss of functionality in crystal play.
But it’s how it is.
Excellent. Now the question is how the core team would feel about such a workarond. @beta-ziliani?
The Snapcraft folks would disagree. In general I agree with you, but when features get cut due to a few bloody icons, I think it goes a bit overboard. But if we can land a compromise everybody can live with, let’s do that.
And the last thing: these changes are going to be merged for Crystal 1.10. Moving forward, @deiv, do you want us to contact you after 1.10 is released to trigger a new build there? Or how would you want to go about releases?