Package Details: vscodium-bin 1.53.2-1

Git Clone URL: (read-only, click to copy)
Package Base: vscodium-bin
Description: Binary releases of VS Code without MS branding/telemetry/licensing.
Upstream URL:
Licenses: MIT
Provides: codium
Submitter: ckatri
Maintainer: sperg512
Last Packager: sperg512
Votes: 40
Popularity: 9.42
First Submitted: 2020-09-23 18:58
Last Updated: 2021-02-15 20:05

Latest Comments

1 2 3 4 Next › Last »

sperg512 commented on 2020-12-20 01:33

yeah i have absolutely no idea what the fuck is happening rn, i just finished my exams and came back to this lol

anyways, @lkrms you can just create a symlink on your own. it'll stay there for each release, as it's just pointing to /usr/bin/codium which is, ofc, updated each release.

@zaandoff will do, internet is spazzing out atm so I don't know when it'll update.

thanks for everyone's feedback, by the way. i think we should just keep it the way it is right now lol

zaandoff commented on 2020-12-20 01:17

Also @sperg512, the PKGBUILD still has conflicts with vscode. Line 22 needs be changed to provides=('codium')


zaandoff commented on 2020-12-19 22:45

I agree as well, that they are separate projects. The names themselves make it clear, and we shouldn't be linking binaries to names that don't match. Especially when there is an AUR package that is for vscode, of which the binary file provided is named code. I would expect that running ln -s /usr/local/bin/codium /usr/local/bin/code is a whole lot easier for anyone who would want that link than manually compiling and installing vscodium every time there is a new release. It makes no sense to link vscodium to code, because it isn't code. Its codium.

cradcore commented on 2020-12-19 22:33

@lkrms This project is VS Codium, not VS Code. Yes, they come from the same code base, but they are not the same project. They are compiled differently and their binaries are different. Therefore, linking /usr/local/bin/code to the codium binary doesn't make sense. Its not the same thing.

If your workflows were broken from the removal of this symlink, can you not just add it yourself to get the same result? Inversely, if the symlink is kept in the PKGBUILD, we can not have VS Code and VS Codium installed at the same time. If you truly have a problem with VS Code not being open source, and that being at odds with the spirit of Arch Linux, then a better place to reach out would be either Microsoft, or the maintaner for the VS Code AUR package, would it not?

Again, this is all said respectfully :)

teras commented on 2020-12-19 12:17

@lkrms Respectfully from my part as well, they are projects with the same root (like OpenOffice and LibreOffice) but with different names and functionality. Yes, indeed they are intended to be as close as possible, but they are not the same, in many aspects.

lkrms commented on 2020-12-19 10:52

@teras Respectfully, they're not separate projects. They're distinct builds of the same project, following identical release schedules and versioning. From the VSCodium home page: "The VSCodium project exists so that you don’t have to download+build from source. This project includes special build scripts that clone Microsoft’s vscode repo, run the build commands, and upload the resulting binaries for you to GitHub releases."

It's supposed to work as a drop-in replacement for VS Code. Removing this symlink disrupts that (IMHO).

teras commented on 2020-12-19 08:36

@ikrms IMHO the one project is called "code", the other "codium". If someone requires "codium" to point to "code", just do so. And as a general Unix user, I feel more comfortable to just create this symlink instead of having to use a platform specific and not everyday used "overwrite" or "nodeps" option instead.

lkrms commented on 2020-12-19 04:05

The removal of /usr/local/bin/code has broken several of my workflows, and the fact that it's only been done to facilitate installation of proprietary extensions that depend on the proprietary build of VS Code seems at odds with the open-source spirit of both VSCodium and Arch Linux, in my opinion. I would have thought users who require such extensions, and are willing to install multiple variants of VS Code to use them (including manually resolving the conflicts that arise from doing so) would receive little benefit from using VSCodium over VS Code and/or be comfortable using pacman's --overwrite and --nodeps options.

But that's just one user's opinion! Thanks for your consistent and responsive efforts maintaining this package :)

sperg512 commented on 2020-12-17 18:27

@cradcore removed, thanks

sperg512 commented on 2020-12-17 18:22

@pryme-svg no need to make a comment, as I already get notifications for new releases + flags out of date. Thanks though