bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <...@apache.org>
Subject Re: Packaging concerns
Date Mon, 22 Aug 2011 16:02:45 GMT
On Sat, Aug 20, 2011 at 11:10 AM, Eric Yang <eyang@hortonworks.com> wrote:
> Greetings big top developers,
>
> Bigtop has started it's own packaging customization build process
> using Linux distributions based packaging tools to fully customize
> Hadoop stack packages.

Just to be clear -- part of the Bigtop charter is to NOT patch the
Apache releases. We are also NOT packaging trunks (or otherwise
unreleased upstream bits) and for the duration of incubation we're
going to make sure that our packages are clearly labeled as coming
from an incubating Apache Bigtop project.

> In traditional GPL camp, meta package
> to build source and apply patches as part of rpm/deb package construction.
> The advantage is that you can apply hot fix to the open source related
> source to customize to fit Linux distributions.

I'm not sure I follow. Can you, please, elaborate?

> In Apache, software are released as tar ball with md5 signature.

Yes. And those are source tarballs. My understanding of Apache
release process is that everything else (including a functional
binaries) is but a convenience artifact. Some of them go into
Maven repositories, some of them go into the same source
release tarballs, but there's no clear process defined for
releasing anything but a source tarball.

> Ideally, Apache released rpm/deb packages should be the same
> bits that is in the release tar ball.

Is there such a thing as Apache released rpm/deb packages
for any project at all? Does Apache have infrastructure to support
those types of packaged releases? I'm very curious to find this out,
simply becuase it'll help Bigtop a lot if we can piggyback off of that
sort of infrastructure and existing efforts.

>  Apache HTTPD project stopped distributing RPM form after a couple short releases.

Ok, so you're saying that Apache is not a correct place to have
packages released?
I'm confused now.

> It seems bigtop has chosen to use traditional Redhat/Debian methodology of producing
bits
> to fit Linux distributions.  It is a novel goal from a packaging purity perspective.

In fact this very subject has been discussed at our meetup last week
(I really wished either
you or Owen could have participated -- but oh well :-(). You're right
that Bigtop has
to decide whether to take the route of producing OS-friendly packages
or tarball-friendly
packages. It seem that the community is currently in favor of the
OS-friendly ones,
but if you have arguments in favor of the other style -- let us know.
Especially if
you have customer feedback that would point in that direction.

That said, the decision, as you can see, is not tied to the packaging
infrastructure
decisions made by various projects. I could very well imagine project A meeting
their customer requirements with one style of packaging and project B pursuing
a different style. That kind of diversity is fine for individual
projects. For Bigtop
we have to stick with one style consistently.

> However, you might want to pay close attention to license and potential pitfalls.

Can you be a bit more clear on what is it that you're referring to as
"license and potential pitfalls"?

> It may be more interesting to focus on testing the community produced packages in MHO.

Where can I get these community produced packages you're referring to? What
projects are included?

Thanks,
Roman.

Mime
View raw message