Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux: provide tar.gz download #12373

Open
core-ai-bot opened this issue Aug 31, 2021 · 11 comments
Open

Linux: provide tar.gz download #12373

core-ai-bot opened this issue Aug 31, 2021 · 11 comments

Comments

@core-ai-bot
Copy link
Member

Issue by rombert
Monday Sep 02, 2013 at 13:26 GMT
Originally opened as adobe/brackets#5021


I've seen that Brackets now has a Linux build, which is great. However, only offering deb files is not friendly towards distros which are not based on Ubuntu, like RedHat, Fedora, SuSE, Gentoo and Arch to name just a few.

If you would provide a tarball which contains the resulting binary files, distro packagers could then provide their own packages based on it.

I understand that providing packages for every possible distro is out of scope, and therefore having a tarball download makes it easier to have other do the packaging :-)

@core-ai-bot
Copy link
Member Author

Comment by ingorichter
Tuesday Sep 03, 2013 at 20:28 GMT


What exactly should be part of the tar ball?
To create the deb package, we stage all required files in one directory and run the tools to produce the deb. There are a lot of files like brackets.desktop, brackets.menu and some icons. What do you think is the minimum set of files to help distro packagers to create a package?

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Wednesday Sep 04, 2013 at 00:17 GMT


@jasonsanjose Is this the kind of thing that would be resolved by the "universal installer" PR?

@core-ai-bot
Copy link
Member Author

Comment by jasonsanjose
Wednesday Sep 04, 2013 at 00:42 GMT


@peterflynn Eh, sort of? All the "universal" change really does is standardize some aspects of packaging then fire off distribution-specific packaging shell scripts.

@rombert I'd like to see some examples of a tarball that you have in mind. At it's simplest, we're basically packaging Chromium (ok...maybe oversimplifying). Chromium's officially supported packaging is .deb and .rpm only (http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/) and the bulk of that packaging is resolving dependencies that aren't compiled into the binary.

@core-ai-bot
Copy link
Member Author

Comment by rombert
Wednesday Sep 04, 2013 at 09:21 GMT


@ingorichter ,@jasonsanjose - The binary tarball IMO should contain everything you package in the deb files, dumped under one directry.

If you look at what Sublime Text 3 does, you get a tarball with a top-level-directory that I can drop into /opt/ and start using. And please keep the desktop/icon files in the tarball, even if they're not installed/registered, as they can be reused by packagers.

@peterflynn - This is I guess orthogonal to the universal installer. Getting a tarball out which will be reused by distro packagers mean that this will potentially end up being installable from distro repositories, rather than manually downloaded from the brackets website, with automatic updates etc.

@core-ai-bot
Copy link
Member Author

Comment by jasonsanjose
Wednesday Sep 04, 2013 at 16:23 GMT


I took a look at the firefox tarball for linux and their install instructions https://support.mozilla.org/en-US/kb/install-firefox-linux. It's interesting that they bundle their library dependencies in the extracted files. I wonder how they determine compatibility and if they do any sort of first-run setup.

@core-ai-bot
Copy link
Member Author

Comment by jasonsanjose
Wednesday Sep 04, 2013 at 16:30 GMT


@rombert I forgot to address your original point about being debian only for now. We were definitely aware of that going in and had considered .deb and .rpm as our first targets for packaging. We're learning as we go here. So, if you have any other suggestions or pointers, or would like to contribute, that would be great. Thanks!

@core-ai-bot
Copy link
Member Author

Comment by rombert
Thursday Sep 05, 2013 at 11:20 GMT


@jasonsanjose

  1. Seems my email regarding Firefox was lost, so here goes. FF does not perform any initial setup and no dependency checking. That's the job of package managers.

I'm not sure how they choose their dependencies, but it doesn't always work. For instance, nightlies don't work on OpenSUSE right now.

  1. Regarding RPM packaging, I'm trying to pick that up for OpenSUSE, but it'd be easer with a tarball. My idea is to package it on the OpenSUSE build service ( think of it as a PPA repository ) and to make it available for everyone to download and receive updates.

The OpenSUSE build service also allows packaging software for Debian/Ubuntu, RHEL/CentOS/Fedora, Arch , but TBH I haven't tried those and I don't plan to.

@core-ai-bot
Copy link
Member Author

Comment by macie
Monday Sep 09, 2013 at 21:44 GMT


@peterflynn "universal installer" is no more than@rombert proposition with my install bash scripts.

I like this idea - one download for all distros.

@core-ai-bot
Copy link
Member Author

Comment by rombert
Wednesday Sep 11, 2013 at 12:07 GMT


@macie - for the end user, I agree. For distro packagers, a tar.gz is much more useful, since we'll be writing our own installers anyway.

At any rate, I've built some OpenSUSE packages for Brackets Sprint 30 - see http://software.opensuse.org/package/brackets . Not sure where (if) I can announce them, but it would be good to get some testing outside my own machine.

@core-ai-bot
Copy link
Member Author

Comment by librehat
Monday Oct 14, 2013 at 13:39 GMT


@jasonsanjose I hope you could provide RPM package in a near future. With a yum repo maintained just like Adobe Flash Player plugin in the old days. While release a generic tarball file is definitely worthwhile, the tarball contains everything just like deb package.

@core-ai-bot
Copy link
Member Author

Comment by lqueryvg
Wednesday Apr 23, 2014 at 10:10 GMT


Sadly I think you have a dependency on glibc 2.15 (via CEF3), which will exclude RHEL/CentOS for quite a while - until RHEL/CentOS 7 comes along.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant