You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Igor Galić <i....@brainsware.org> on 2013/11/10 14:26:32 UTC
Semi Official Package Repo
Hi folks,
Inspired by PostgreSQL's move[1][2], I've been considering to
go down the road of offering (at least) RPM and Deb packages*
for CentOS/Fedora, Debian/Ubuntu of the latest supported
Apache Traffic Server releases.
This would increase the initial effort on our side considerably,
but also cut *down* in user support negotiation, e.g.:
* How did you compile your version of ATS?
* Oh, but did you remember to install these libraries before?
* please use <binary> -- I don't have <binary> -- Oh, you forgot
to install <library> before compiling…
It would also considerably increase the adoption rate of new
releases as it did in the case of PostgreSQL.
Please consider that I don't know the exact legal status in the
case of the PostgreSQL Foundation, but since the only product
the ASF legally supports is source code, those packages would be,
as the Subject suggests, only semi-official.
I'd like to get feedback from both, developers (and packagers)
as well as users. If someone wants to jump in and volunteer to
create either of those please do that also ;)
So long,
Igor
[1] https://wiki.postgresql.org/wiki/YUM_Installation
[2] https://wiki.postgresql.org/wiki/Apt
* why not FreeBSD or Solaris? Because those people are assumed
to know how to compile new software ;)
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Semi Official Package Repo
Posted by Leif Hedstrom <zw...@apache.org>.
On Nov 10, 2013, at 6:26 AM, Igor Galić <i....@brainsware.org> wrote:
>
>
> Hi folks,
>
> Inspired by PostgreSQL's move[1][2], I've been considering to
> go down the road of offering (at least) RPM and Deb packages*
> for CentOS/Fedora, Debian/Ubuntu of the latest supported
> Apache Traffic Server releases.
There is some precedence here for e.g. OpenOffice.
-- Leif
>
> This would increase the initial effort on our side considerably,
> but also cut *down* in user support negotiation, e.g.:
>
> * How did you compile your version of ATS?
> * Oh, but did you remember to install these libraries before?
> * please use <binary> -- I don't have <binary> -- Oh, you forgot
> to install <library> before compiling…
>
> It would also considerably increase the adoption rate of new
> releases as it did in the case of PostgreSQL.
>
> Please consider that I don't know the exact legal status in the
> case of the PostgreSQL Foundation, but since the only product
> the ASF legally supports is source code, those packages would be,
> as the Subject suggests, only semi-official.
>
> I'd like to get feedback from both, developers (and packagers)
> as well as users. If someone wants to jump in and volunteer to
> create either of those please do that also ;)
>
> So long,
>
> Igor
>
> [1] https://wiki.postgresql.org/wiki/YUM_Installation
> [2] https://wiki.postgresql.org/wiki/Apt
> * why not FreeBSD or Solaris? Because those people are assumed
> to know how to compile new software ;)
>
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
>
Re: Semi Official Package Repo
Posted by Leif Hedstrom <zw...@apache.org>.
On Nov 10, 2013, at 6:26 AM, Igor Galić <i....@brainsware.org> wrote:
>
>
> Hi folks,
>
> Inspired by PostgreSQL's move[1][2], I've been considering to
> go down the road of offering (at least) RPM and Deb packages*
> for CentOS/Fedora, Debian/Ubuntu of the latest supported
> Apache Traffic Server releases.
There is some precedence here for e.g. OpenOffice.
-- Leif
>
> This would increase the initial effort on our side considerably,
> but also cut *down* in user support negotiation, e.g.:
>
> * How did you compile your version of ATS?
> * Oh, but did you remember to install these libraries before?
> * please use <binary> -- I don't have <binary> -- Oh, you forgot
> to install <library> before compiling…
>
> It would also considerably increase the adoption rate of new
> releases as it did in the case of PostgreSQL.
>
> Please consider that I don't know the exact legal status in the
> case of the PostgreSQL Foundation, but since the only product
> the ASF legally supports is source code, those packages would be,
> as the Subject suggests, only semi-official.
>
> I'd like to get feedback from both, developers (and packagers)
> as well as users. If someone wants to jump in and volunteer to
> create either of those please do that also ;)
>
> So long,
>
> Igor
>
> [1] https://wiki.postgresql.org/wiki/YUM_Installation
> [2] https://wiki.postgresql.org/wiki/Apt
> * why not FreeBSD or Solaris? Because those people are assumed
> to know how to compile new software ;)
>
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
>
Re: Semi Official Package Repo
Posted by Jean Baptiste Favre <we...@jbfavre.org>.
Hello,
I updated Debian package for my company internal use, currently
trafficserver 3.2.5, just finished 4.0.2 and will work on 4.1 soon.
I guess it could be possible for me to share it.
So, I would be happy to contribute that way :)
Regards,
JB
On 10/11/2013 14:26, Igor Galić wrote:
>
> Hi folks,
>
> Inspired by PostgreSQL's move[1][2], I've been considering to
> go down the road of offering (at least) RPM and Deb packages*
> for CentOS/Fedora, Debian/Ubuntu of the latest supported
> Apache Traffic Server releases.
>
> This would increase the initial effort on our side considerably,
> but also cut *down* in user support negotiation, e.g.:
>
> * How did you compile your version of ATS?
> * Oh, but did you remember to install these libraries before?
> * please use <binary> -- I don't have <binary> -- Oh, you forgot
> to install <library> before compiling…
>
> It would also considerably increase the adoption rate of new
> releases as it did in the case of PostgreSQL.
>
> Please consider that I don't know the exact legal status in the
> case of the PostgreSQL Foundation, but since the only product
> the ASF legally supports is source code, those packages would be,
> as the Subject suggests, only semi-official.
>
> I'd like to get feedback from both, developers (and packagers)
> as well as users. If someone wants to jump in and volunteer to
> create either of those please do that also ;)
>
> So long,
>
> Igor
>
> [1] https://wiki.postgresql.org/wiki/YUM_Installation
> [2] https://wiki.postgresql.org/wiki/Apt
> * why not FreeBSD or Solaris? Because those people are assumed
> to know how to compile new software ;)
>
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
>
>
> !DSPAM:527f89b718421142027061!
>
>
Re: Semi Official Package Repo
Posted by Gary Law <ga...@gmail.com>.
Igor
I've maintained some FOSS packages before, although not for an Apache project. If you need assistance let me know.
Gary
—
Gary Law
garylaw@garylaw.net
@garylawuk
Re: Semi Official Package Repo
Posted by David Boreham <da...@bozemanpass.com>.
On 11/11/2013 12:26 AM, Jan-Frode Myklebust wrote:
> Why not use the packages in official Fedora/EPEL? Do you intend to have
> much less strict policy of publishing incompatible upgrades ?
>
As a user of the Postgresql RPM repository, I can say that I would not
want to pull packages from EPEL (and similar sources such as repoforge)
onto production machines. This is due to unpleasant past experiences
where the use of these repositories introduced broken dependencies of
various kinds onto systems that were time consuming to diagnose and fix.
The Postgresql repository has the nice property that it gives you PG and
only PG and nothing else you didn't expect or want.
That said, ATS is much easier to build than Postgresql. Anyone using it
seriously in production would most likely make their own RPM. Therefore
perhaps EPEL is ok for the tire-kicking type installs.
Re: Semi Official Package Repo
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
On Sun, Nov 10, 2013 at 01:26:32PM +0000, Igor Galić wrote:
>
> Inspired by PostgreSQL's move[1][2], I've been considering to
> go down the road of offering (at least) RPM and Deb packages*
> for CentOS/Fedora, Debian/Ubuntu of the latest supported
> Apache Traffic Server releases.
Why not use the packages in official Fedora/EPEL? Do you intend to have
much less strict policy of publishing incompatible upgrades ?
I would much rather see the Fedora and EPEL packages being blessed as
official ATS packages (and would love some help maintaining/testing them).
I don't think there should be much problem having EPEL running at latest
release, but fedora might have a bit more strict policy against
incompatible upgrades within a fedora-release.
I fear that if ATS starts pushing out-of-distro packages as the
preferred version to run, my effort to maintain it in Fedora/EPEL will
be a waste -- and we might end up without ATS natively in Fedora/EPEL.
-jf
Re: Semi Official Package Repo
Posted by Jan-Frode Myklebust <ja...@tanso.net>.
On Sun, Nov 10, 2013 at 01:26:32PM +0000, Igor Galić wrote:
>
> Inspired by PostgreSQL's move[1][2], I've been considering to
> go down the road of offering (at least) RPM and Deb packages*
> for CentOS/Fedora, Debian/Ubuntu of the latest supported
> Apache Traffic Server releases.
Why not use the packages in official Fedora/EPEL? Do you intend to have
much less strict policy of publishing incompatible upgrades ?
I would much rather see the Fedora and EPEL packages being blessed as
official ATS packages (and would love some help maintaining/testing them).
I don't think there should be much problem having EPEL running at latest
release, but fedora might have a bit more strict policy against
incompatible upgrades within a fedora-release.
I fear that if ATS starts pushing out-of-distro packages as the
preferred version to run, my effort to maintain it in Fedora/EPEL will
be a waste -- and we might end up without ATS natively in Fedora/EPEL.
-jf