Yup, -bigtop is even better! Cos
On Tue, Sep 24, 2013 at 12:09AM, Bruno Mahé wrote: > I agree with Cos that a suffix makes it easier to find. > But I would lean toward "-bigtop" since "-asf" may be vague in some > cases (ie. what if Apache Hadoop starts to also name its own packages > hadoop-asf?). > Using "-bigtop" also makes the brand/project more recognizable and > easier to look for in search engines. > > > Thanks, > Bruno > > > On 09/23/2013 06:16 PM, Konstantin Boudnik wrote: >> Sorta what I suggested with 'spark-asf'. It'd better than 'apache-' prefix, >> because it would be easier to find, sorta... >> >> Cos >> >> On Mon, Sep 23, 2013 at 04:37PM, Peter Linnell wrote: >>> Putting on my Linux distro hat... I've long been involved with >>> openSUSE... >>> >>> I'd say apache-spark would be best, but this adds minor baggage to >>> packaging. >>> >>> Thoughts ? >>> >>> Thanks, >>> Peter >>> >>> On Mon, 23 Sep 2013 16:01:32 -0700 >>> Konstantin Boudnik <[email protected]> wrote: >>> >>>> On Mon, Sep 23, 2013 at 06:24PM, Jay Vyas wrote: >>>>> Why not call it bigtop-spark .. ? >>>> >>>> Well, because it isn't bigtop's spark, to start with ;) >>>> >>>>> Seems to me like nobody but the root project itself should >>>>> monopolize the hadoop distro primary names since there are so many >>>>> builds out there... Right? >>>> >>>> What's is root project, sorry? >>>> >>>>>> On Sep 23, 2013, at 4:11 PM, Konstantin Boudnik <[email protected]> >>>>>> wrote: >>>>>> >>>>>> I'd say Fedora needs to deal with it on their end, considering >>>>>> that they are coming into this post-Bigtop. Thoughts? >>>>>> >>>>>>> On Mon, Sep 23, 2013 at 11:43AM, Sean Mackrory wrote: >>>>>>> I've been worried about this for a while, and I think we need to >>>>>>> come up with a strategy for dealing with it in Bigtop. In this >>>>>>> case, it's just a coincidence that two separate projects are >>>>>>> named Spark. However I recently submitted a patch for packaging >>>>>>> Avro as a separate component in Bigtop and had to deal with the >>>>>>> fact that a minority of the systems we support already packaged >>>>>>> part of Avro in a package named 'avro', so I had to use >>>>>>> 'avro-libs', 'avro-tools' and 'avro-doc'. Fedora's also going to >>>>>>> start releasing packages for Hadoop, so this problem of name >>>>>>> conflicts is only going to get worse. >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 23, 2013 at 10:52 AM, Konstantin Boudnik >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Let's call it spark-asf, perhaps? >>>>>>>> >>>>>>>>> On Mon, Sep 23, 2013 at 09:57AM, Roman Shaposhnik wrote: >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> While testing Spark as part of the Bigtop I've come >>>>>>>>> across the following conflict on Debian-based systems: >>>>>>>>> >>>>>>>>> $ apt-cache show spark >>>>>>>>> Package: spark >>>>>>>>> Priority: optional >>>>>>>>> Section: universe/devel >>>>>>>>> Description-en: SPARK programming language toolset >>>>>>>>> SPARK is a formally-defined computer programming language >>>>>>>>> based on the Ada programming language, intended to be secure >>>>>>>>> and to support the development of high integrity software used >>>>>>>>> in applications and systems where predictable and highly >>>>>>>>> reliable operation is essential either for reasons of safety >>>>>>>>> or for business integrity. . >>>>>>>>> This package contains the tools necessary for checking if >>>>>>>>> programs >>>>>>>> adhere >>>>>>>>> to the SPARK rules and the tools to show freedom of runtime >>>>>>>>> exceptions >>>>>>>> in >>>>>>>>> those programs. To compile SPARK programs use any >>>>>>>>> standards-compliant >>>>>>>> Ada >>>>>>>>> compiler, such as GNAT. >>>>>>>>> Homepage: >>>>>>>>> http://libre.adacore.com/libre/tools/spark-gpl-edition/ >>>>>>>>> >>>>>>>>> >>>>>>>>> This has an obvious ramifications for Bigtop packaging, but >>>>>>>>> it may also have ramifications for PODLINGNAMESEARCH >>>>>>>>> for Apache Spark (incubating). >>>>>>>>> >>>>>>>>> Speaking of which -- has anybody else started PODLINGNAMESEARCH >>>>>>>>> already? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Roman. >>>>>>>> >>> >
