Bigtop package renames

[Roman Shaposhnik <rv...@apache.org>]

This is a friendly reminder that the following pacakge renames
have happened in all of the Bigtop branches:
   hadoop-zookeeper -> zookeeper
   hadoop-hbase -> hbase
   hadoop-hive -> hive
   hadoop-pig -> pig

The puppet code and the test code has been updated, but if you
happen to install packages by hand you should retrain yourself
not to type hadoop- prefix anymore.

Now, while the rename was happening, Peter has made an excellent point
on this JIRA:
   https://issues.apache.org/jira/browse/BIGTOP-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177854#comment-13177854

So here's a question to you all: what level of backward looking packaging
magic would be desirable to have in Bigtop? On one hand, we're still
pretty young so pretending that nothing happened (and keeping our
package code cleaner) is one option.

Alternatively we can go wild with things like Provides, Replaces, etc.

Thoughts?

Thanks,
Roman.

Re: Bigtop package renames

[Peter Linnell` <pl...@cloudera.com>]

On 01/09/2012 09:51 AM, Roman Shaposhnik wrote:
> On Tue, Jan 3, 2012 at 10:04 PM, Peter Linnell<pl...@cloudera.com>  wrote:
>> One other wrinkle is the proposed release of Hadoop 1.0, which based on
>> 0.20.x will be a "newer version" than 0.23.
>>
>> We definitely need to have a solution for this. Something like
>>
>> Provides: hadoop-1.0+x
>
> I guess I'm less concerned about some other package still
> depending on something that we've renamed and more
> concerned about how the installation of a brand new
> stack of Bigtop will proceed where a previous Bigtop
> has been installed before.
>
> So let me see if I understand. To the best of my knowledge, the only
> two keywords that RPM provides for managing situations where packages
> with different names have some kind of a relationship are:
>     Conflicts
>     Obsoletes
>
> With the only difference being that Obsoletes would allow upgrade and
> Conflict would require manual removal and then installation.
>
> Am I missing anything?
>
> Thanks,
> Roman.

Third option Provides:

If package B depends on package A, which is renamed, then unless rpm 
discovers via its own magic that package A Provides: OldpackageA, then 
there might be a missing dependency for B.

Obsoletes is yes for upgrading a older package, with a newer renamed 
package.

Conflicts is more to prevent two packages being installed which have 
some kind of file or binary conflict.

Eg postfix and exim both provide and mts and its difficult to install both.

In the case of upgrading an older bigtop package, we merely need to make 
sure either rpm autogenerates or an explicit Provides is included.

Provides is not so much for upgrades, but to ensure other packages can 
find their dependencies via rpm.

Clearer ?

Thanks,

Peter

Re: Bigtop package renames

[Roman Shaposhnik <rv...@apache.org>]

On Tue, Jan 3, 2012 at 10:04 PM, Peter Linnell <pl...@cloudera.com> wrote:
> One other wrinkle is the proposed release of Hadoop 1.0, which based on
> 0.20.x will be a "newer version" than 0.23.
>
> We definitely need to have a solution for this. Something like
>
> Provides: hadoop-1.0+x

I guess I'm less concerned about some other package still
depending on something that we've renamed and more
concerned about how the installation of a brand new
stack of Bigtop will proceed where a previous Bigtop
has been installed before.

So let me see if I understand. To the best of my knowledge, the only
two keywords that RPM provides for managing situations where packages
with different names have some kind of a relationship are:
   Conflicts
   Obsoletes

With the only difference being that Obsoletes would allow upgrade and
Conflict would require manual removal and then installation.

Am I missing anything?

Thanks,
Roman.

Re: Bigtop package renames

[Peter Linnell <pl...@cloudera.com>]

On 01/03/2012 06:30 PM, Roman Shaposhnik wrote:
> This is a friendly reminder that the following pacakge renames
> have happened in all of the Bigtop branches:
>     hadoop-zookeeper ->  zookeeper
>     hadoop-hbase ->  hbase
>     hadoop-hive ->  hive
>     hadoop-pig ->  pig
>
> The puppet code and the test code has been updated, but if you
> happen to install packages by hand you should retrain yourself
> not to type hadoop- prefix anymore.
>
> Now, while the rename was happening, Peter has made an excellent point
> on this JIRA:
>     https://issues.apache.org/jira/browse/BIGTOP-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177854#comment-13177854
>
> So here's a question to you all: what level of backward looking packaging
> magic would be desirable to have in Bigtop? On one hand, we're still
> pretty young so pretending that nothing happened (and keeping our
> package code cleaner) is one option.
>
> Alternatively we can go wild with things like Provides, Replaces, etc.
>
> Thoughts?
>
> Thanks,
> Roman.

One other wrinkle is the proposed release of Hadoop 1.0, which based on 
0.20.x will be a "newer version" than 0.23.

We definitely need to have a solution for this. Something like

Provides: hadoop-1.0+x

Is hackish, but might work.

Using epoch is another possibility for rpm, but I am generally allergic 
to using it. Once you do, you are stuck with it forever.

Cheers,
Peter