Re: Why still no an official package for RHEL or Ubuntu?

[Dvir Volk]

Side note: Ubuntu 12.10 includes Redis 2.4.17 in it (that was the latest stable version when it came out) and probably will move to 2.6 on 13.04.

Building redis is extremely easy: apart from a compiler and the standard libraries and make, it has no dependencies. it has a service installation script you can run after the initial "make install", that installs the service and supports both Ubuntu and RH.

On Wed, Oct 24, 2012 at 6:50 PM, Howard <howa...@gmail.com> wrote:

Not sure if this question has been answered in the past, but as 2.6 just come out I am wondering why we still don't have an official package?

As there are quite a lot of effort being made in boosting the redis community such as good documentation, e.g. http://redis.io/documentation

Why don't provide an official package for RHEL or Ubuntu so make it easy for beginner, so they don't need to ask..

Q. Where can I find the init script?

Q. What permission is needed for the db directory etc?

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/BUPt4e3sgBMJ.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

--

Dvir Volk

Chief Architect, Everything.me

http://everything.me 

[M. Edward (Ed) Borasky]

I can't speak for Ubuntu - I don't know their process - but in the
case of Fedora, you need

a. A packager inside the Fedora project
b. Someone in the Redis community willing to do what's necessary to
interface with the Fedora community

You also have to be aware of scheduling and resource constraints.
Fedora (and Ubuntu) are *calendar*-based distributions. Dates matter.
If a release doesn't pass the quality gates by the cutoff date, it
doesn't make it into the distro release.

Fedora 18 is somewhere between alpha and beta - I haven't looked at
the road map recently. My guess is that Redis 2.6 won't be in 18,
although I can ask on the Fedora mailing list if that's the case, or
one can simply search for "Fedora 18 Redis". I'd recommend reaching
out to the Fedora Redis packager (Google should be able to find the
right person) directly. Give them what they need when they need it,
and Redis 2.6 will show up in Fedora as soon as all the quality and
timing gates are met.

Once it's in Fedora, it's up to Red Hat the *business* when it makes
it into RHEL. I'd be surprised if anything makes it into RHEL without
having been through the Fedora process except when Red Hat buys a
company that makes something.

Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?

[Howard]

Hi,

On Thursday, October 25, 2012 4:07:23 AM UTC+8, M Edward Borasky wrote:

I can't speak for Ubuntu - I don't know their process - but in the
case of Fedora, you need

a. A packager inside the Fedora project
b. Someone in the Redis community willing to do what's necessary to
interface with the Fedora community

 

Some confusion..

I am not saying Ubuntu should always have the latest stable of redis-server, it never works, even talking about using PPA.

I am saying using similar approach like MongoDB (custom repository), the provider provide official package and user can always have the latest stable

(http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/)

I agree compiling is easy but why not make it even better? e.g. more standardized init script, folder path and permissions etc.

[Shakthi Kannan]

Hi,

--- On Wed, Oct 24, 2012 at 10:20 PM, Howard <howa...@gmail.com> wrote:
| Why don't provide an official package for RHEL or Ubuntu so make it easy for
| beginner, so they don't need to ask..

\--

redis-2.4.10-1 is available on Fedora 17.

https://admin.fedoraproject.org/pkgdb/acls/name/redis

You can ask the maintainer to update the package with the latest
release. There were builds made for EL6 which are available through
EPEL for CentOS (for example):

http://koji.fedoraproject.org/koji/packageinfo?packageID=11032

http://fedoraproject.org/wiki/EPEL

SK

--
Shakthi Kannan
http://www.shakthimaan.com

[Dvir Volk]

I actually want to do this, let's see if I have time this weekend. not promising anything but a PPA would be nice for my servers as well. 

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.

To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/7zkDeqcwoHcJ.

To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

[M. Edward (Ed) Borasky]

If there haven't been any build-time or run-time dependency changes
between 2.4.x and 2.6.0, it's probably just changing out the tarball
in the source RPM, running a bunch of QA tests and getting the
appropriate sign-offs. I've been running Redis 2.6.0 on Fedora 17 for
weeks without issues.

Perhaps a more interesting topic than getting 2.6.0 into the Linux
distros is getting it into the "packaged" Platform-as-a-Service
offerings. Cloud Foundry and its numerous spin-offs runs on Ubuntu LTS
and Red Hat's OpenShift runs on a mix of RHEL 6 and Fedora. I fooled
around a bit with both in May and June before deciding to avoid the
server space in favor of desktops.

[Felix Gallo]

I think trying to make 'official packages' for redis is a mistake.
What configuration file do you ship? What disk policy? If it's
persistent, where do you store the data files? What is the memory
size limit you impose? Is this memory size true for 256M installs and
256G installs? 32 bit, or 64 bit? What file descriptor does it
listen to?

Redis is in a position which is essentially directly inimical to
linux-style 'package management' -- it's trivial to compile, it has a
number of tricky configuration options which radically change its use
case and its footprint, it is a fast moving project that frequently
issues bug updates, and used incorrectly it can annihilate a server.
And that's even before considering that it needs active systems
management, such as port protection, a backup / retention strategy,
log rotation, etc.

Being able to download the files from github, install them and
configure them seems to me to be the least possible hurdle to becoming
a redis user -- and would have the added advantages of keeping this
list free from the deluge of 'how i use redis.php??' or 'redis blew up
my m1.small!!!11!' that seems otherwise inevitable...

F.

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.

[M. Edward (Ed) Borasky]

On Thu, Oct 25, 2012 at 10:29 AM, Felix Gallo <felix...@gmail.com> wrote:
> I think trying to make 'official packages' for redis is a mistake.
> What configuration file do you ship? What disk policy? If it's
> persistent, where do you store the data files? What is the memory
> size limit you impose? Is this memory size true for 256M installs and
> 256G installs? 32 bit, or 64 bit? What file descriptor does it
> listen to?
>
> Redis is in a position which is essentially directly inimical to
> linux-style 'package management' -- it's trivial to compile, it has a
> number of tricky configuration options which radically change its use
> case and its footprint, it is a fast moving project that frequently
> issues bug updates, and used incorrectly it can annihilate a server.
> And that's even before considering that it needs active systems
> management, such as port protection, a backup / retention strategy,
> log rotation, etc.
>
> Being able to download the files from github, install them and
> configure them seems to me to be the least possible hurdle to becoming
> a redis user -- and would have the added advantages of keeping this
> list free from the deluge of 'how i use redis.php??' or 'redis blew up
> my m1.small!!!11!' that seems otherwise inevitable...
>
> F.

If it's properly managed, it's an advantage for the Redis technology.
Since Redis 2.4 is already packaged in the major community distros -
Debian/Ubuntu/Linux Mint, Fedora/CentOS, Gentoo and probably others -
the distro-specific configuration and devops engineering work has
already been done and people are using Redis 2.4 in production on
those distros. All we're talking about, or at least all I'm talking
about, is expending the modest amount of Redis community effort
required to facilitate upgrading 2.4 stable to 2.6 stable in as many
places as possible. I'd say Ubuntu is the highest priority, followed
by Fedora. openSUSE and Gentoo will do their own thing, and I'm
guessing Mageia will as well. Once Ubuntu and Fedora are nailed down,
push towards Cloud Foundry and OpenShift.

A few months ago I hit a wall trying to build some things on "stock"
openSUSE Linux / SUSE Studio. So I decided to refactor into a set of
core tools I get from Linux and packages I build from upstream source.
That way, I can run on Ubuntu / Mint, openSUSE and Fedora. Redis is
part of the tool set I build from upstream source. But once 2.6 has
been packaged in openSUSE-, Ubuntu- and Fedora-compatible
repositories, that's going to change. It's one less chunk of code I
have to maintain.

[Felix Gallo]

On Thu, Oct 25, 2012 at 12:38 PM, M. Edward (Ed) Borasky
<zn...@znmeb.net> wrote:
> [...]

> If it's properly managed, it's an advantage for the Redis technology.

I'm not sure that's right. Does it increase popularity, from a marketing or
advertising perspective? I would argue no, because it's not like apt-get
is an app store with featured packages and discoverability. Instead,
you get:

> Since Redis 2.4 is already packaged in the major community distros -
> Debian/Ubuntu/Linux Mint, Fedora/CentOS, Gentoo and probably others -
> the distro-specific configuration and devops engineering work has
> already been done and people are using Redis 2.4 in production on

> those distros. [...]

I went and looked, and there is essentially no distro-specific configuration
and also essentially no devops engineering work. The 'long term support'
release of Ubuntu, the one recommended for production, ships a super
old buggy version of redis 2.2. It includes no memory limits, uses rdb
instead of aof, listens on 6379 only.

I get that there are warm fuzzies to be had about being somehow
acknowledged by the major open source distributions as being a worthy
package to include in their offering. Giving people a dusty old loaded handgun
with bad instructions written in ancient Aramaic, on the other hand, that's not
great.

It might just be my opinion, but it seems to me like redis is not a good idea
for people who can't be bothered to download the source and need a package.
Conversely, packages are a great idea for highly stable, non-system-threatening,
non-complex tools like grep, awk, sed...

F.

[Brian P O'Rourke]

A related issue to this discussion is the issue of shared libraries,
previously discussed/resolved here:

https://github.com/antirez/redis/pull/137

That said, Chris Lamb maintains a Debian package here:

https://github.com/lamby/pkg-redis


Cheers,
Brian