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

Smashing Debian Package #39

Closed
terraboops opened this issue Jan 6, 2017 · 8 comments
Closed

Smashing Debian Package #39

terraboops opened this issue Jan 6, 2017 · 8 comments

Comments

@terraboops
Copy link

Make Smashing easy to install on Ubuntu.

@fredex2
Copy link

fredex2 commented Feb 5, 2017

The package installation shall be a script or a package uploaded to the Debian/Ubuntu repository system (for automatic installation)?

@terraboops
Copy link
Author

Good question! I don't know how this works exactly. I just want to make it really easy for people to install.

I suppose if we make a Debian package, we will have to find a place to host it. I don't know how that works, but I imagine it to be difficult. Anyone have any insights into this?

@tyler-mauthe-hs
Copy link
Contributor

There's this:
https://github.com/krobertson/deb-s3

But then we'd have to pay for S3 hosting 😿

I've worked with projects in CentOS where they provide a 'Source RPM' that allows you to build an RPM and install. I wonder if there's a Debian equivalent?

Or maybe we should just do as you suggested and build some sort of installation script...

@kinow
Copy link
Member

kinow commented Feb 6, 2017

I believe you can host it on launchpad for free, or you can ask for an official package in Ubuntu and Debian repositories (would have to ask someone like @rbrito about that)

@terraboops
Copy link
Author

Looks promising! Thanks @kinow

https://help.launchpad.net/Packaging/PPA

@webmaster128
Copy link

What is the advantage of having a Debian package over installation via ruby gems? I am a hardcore Ubuntu and It love the packaging system, but still I don't see how this is worth the effort. Isn't it better to concentrate on the installation method that works for all Linux distributions and OSX at the same time?

@tyler-mauthe-hs
Copy link
Contributor

@webmaster128 Maybe this is a relic from Dashing, but we used to get a TON of support requests from poor sysadmin type folks who'd never used Ruby and had no idea how to install gems or why they were failing to install on .

I'm thinking though that a docker container might increasingly be the better option.

@kinow
Copy link
Member

kinow commented Apr 21, 2017

Not only that @tylermauthe . At $work$ I normally have to install Smashing in Red Hat (RH), so will use YUM for example, but probably the same can be applied to a company that does similar thing with Debian based distros.

Some companies that use RH also use Red Hat Satellite or the Open Source Foreman to manage dependencies version.

The servers will use only the internal repository from Satellite/Foreman. And system engineers are able to create a versioned set of dependencies, e.g. VERSION1, and apply it to environments in production/dev/uat/etc.

Then someone decides to install Smashing (I'm normally at this point, requesting the installation).

A system engineer will start a test bed environment and create VERSION2, based on VERSION1. Then will install the dependencies for smashing via YUM. He is able to patch dependencies if necessary (some companies need to comply with security guidelines, etc).

If everything works fine, VERSION2 will be marked as available for dev environment via Foreman/Satellite. Then will roll out the change and test Smashing. If everything is fine, then will apply the same VERSION2 to uat/production.

This is a more bureaucratic & lengthy process than most companies I reckon. But some companies (banks, research institutes, government agencies, etc) may have to adopt a process like this.

One must is using the package manager to be able to trace back changes, and what is installed or not. Other artefacts installed via Node, Gem, PHP Composer, etc, are normally blocked, as this could conflict with other packages installed via YUM.

Said all that; if we do not have the resources to distribute RPM/DEB packages, then I'd be happy with Docker. What I did in the past, was to set-up a job in Jenkins to generate a Smashing RPM myself, then go through an internal process to approve the RPM to be uploaded to our internal repository, then distributed to the servers.

Just wanted to point that there are valid reasons for having Linux distribution packages over ruby gems.

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

5 participants