As a sys.admin with 8 years in the field I can only agree with the statement: if one installs a software from a native OS package it is only expected that the software and the package layout is inlined with the OS guidelines and expectations.
So, I like proposed idea exactly for that exact reason: BigTop is trying to provide a native OS experience for users who have chosen to use out stacks. And let's make these stacks to work nicely with their OS of choice. I would also like to bring to the attention of the community one simple fact: BigTop (incubating) doesn't release binary artifacts, thus the structure of BigTop (incubating) binaries shouldn't be a concern similar to one, that has been harped back and forth on incubator-general list just recently. Cos On Thu, May 03, 2012 at 05:59PM, Andrew Purtell wrote: > Matt: > > It seems that this is carelessly discarding what is being practiced at a > > lot of > > sites, because you'd rather do it this way. ═Generally speaking, we make > > the Hadoop Ecosystem easier to use by adhering to familiar usage, rather > > than diverging. ═Please give reasons for the divergence. > > Roman: > > > Basically there are 2 types of packages on any operating system -- the > > ones that try to follow the rules of the underlying OS and the ones that > > strive to be cross-platform at the expense of playing nice with an > > underlying > > system. One type typically gets installed into all the right locations from > > the FHS stand point and the other ones typically have a self-contained > > trees down at /opt. Both are legitimate. HADOOP-6255 is neither. > > As a longtime Linux administrator and Hadoop user, I feel comfortable stating > that Hadoop as distributed by Apache is not packaged to conform to OS > conventions. From ad hoc directory layouts to reams of inscrutable XML > configuration to start/stop scripts each with slightly different semantics > (is it "hdfs namenode start" or "hdfs namenode" or "hbase master start" or > "hbase master" or ...) to incompatible copies of core jars littering the > classpath... frankly, more like the crazy cousin from the country who moves > in with city relatives and unpacks all of their stuff in the living room. > > This is obviously a nonbinding but enthusiastic +1 for the approach I've seen > here so far. One day I hope I no longer have to ls / find / grep all over the > filesystem to extract unsuspecting dev teams from JAR hell, no matter if > Apache Hadoop or Apache Pig or Apache Oozie or Apache HBase (guilty of the > "Apache way" too) want to continue packaging all of their dependencies > whatever they were at the time of 'mvn package' this week or that. > > Best regards, > > > ═ ═ - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein (via > Tom White)
signature.asc
Description: Digital signature
