Why rpm5 and smart for Belenix

2011-09-03 Thread Sriram Narayanan
All:

For various reasons, we'd chosen to use rpm5 + smart for Belenix [1]

There was some recent development in the openindiana and illumos
communities, where Nexenta has reiterated that they would continue to
use their modified (or rather enhanced to be ZFS-aware) version of
dpkg + apt-get. I had an email exchange with Garrett, who is one of
the founding members of Illumos as well as a senior officer at
Nexenta.

The Belenix team will continue to use rpm5 and the smart package manager.

-- Sriram

[1] 
http://www.belenix.org/content/Proposal-use-rpm5-package-format-and-smart-package-manager

-- Forwarded message --
From: Sriram Narayanan sri...@belenix.org
Date: Sat, Sep 3, 2011 at 8:54 PM
Subject: Fwd: About dpkg and apt-get
To: Belenix Developers belenix-...@opensolaris.org


All:

Summary: I asked Garrett D'Amore of Nexenta/Illumos on Nexenta's
choice of using dpkg despite lack of clarity from Debian Legal. With
his permission, I'm forwarding his response to this mailing list.

My thoughts:
We should continue to use rpm5 and the smart package manager, given
the friendliness of the rpm5 team and the smart team with helping
others with adopting their technology in contrast to throwing
obstacles.


-- Ram


-- Forwarded message --
From: Sriram Narayanan sri...@belenix.org
Date: Sat, Sep 3, 2011 at 1:12 AM
Subject: Re: About dpkg and apt-get
To: Garrett D'Amore garr...@damore.org


On Sat, Sep 3, 2011 at 1:07 AM, Garrett D'Amore garr...@damore.org wrote:

 On Sep 2, 2011, at 11:31 AM, Sriram Narayanan wrote:

 Hi Garrett:

 It has been my impression that the Debian Legal community hasn't given
 a clear answer to whether they're fine with dpkg being used on a
 non-GPL kernel [1]

 I don't see that it matters.  The GPL is pretty clear here… the functional 
 boundary of the dpkg code is a self contained program, and the GPL has been 
 very clear that running GPL programs on proprietary kernels is fine.


 I also saw the IRC logs of the oi-meeting from earlier this week, and
 noted that you've mentioned that Nexenta will continue to use the dpkg
 format.

 For Belenix, we've been wary of getting into a mess at some future
 date, since we are a small group and don't have the wherewithal to get
 into an argument with Debian Legal. I therefore proposed that we use
 rpm5 + smart [2] and we're making some amount of progress on this. [3]
 [4]

 If possible, could you share with me your thoughts on using dpkg and
 how you feel that Nexenta would deal with disagreements with Debian
 Legal in the future ?

 I've had conversations with the Debian folks on this.  The challenge/debate 
 has always been the proprietary libc, not the kernel.  And it centers around 
 defining what is a derivative product, and the differences between derivation 
 and consolidation.

 The only guys who are fighting this are the guys with an axe to grind about 
 Linux.  In my estimation, and the estimation of at least one very well-known 
 lawyer familiar with this matter (i.e. my legal council), the interpretation 
 that would prevent using GPL user land software on a proprietary OS is 
 unreasonable, and clearly not the most logical interpretation of the GPL 
 language itself.

 The thing is for them to come after us, they would have to come after *every* 
 commercial non-GPL system that ships dpkg -- I think this includes Oracle and 
 Apple, and probably other companies as well.

 The *format* of the packages is irrelevant, its just the package manager 
 itself.

 At the end of the day, this is all FUD, and it was used to create a barrier 
 to our more broad participation in the Debian community, but my read of this 
 was that it was really done simply because we were not Linux, and that some 
 OS bigotry came into play and this was a way to keep us out.

 Its really silly, because the bone of contention was *not* a proprietary 
 libc, but one that has a copyleft as well with just slightly incompatible 
 terms with the GPL.  In fact, all reasonable open source advocates really 
 understand that the spirit of our libc is completely compatible with the 
 spirit of the GPL -- its just the guys with a political agenda that like to 
 spread licensing FUD.

 We have chosen to recognize the FUD for what it is, and ignore the concerns 
 of those spreading it.


Thanks for your response, Garrett. Overall, Moinak and I share the
same opinion with you on dpkg.

I also didn't have context earlier on libc, now thanks to you, I do.


 I'll share your responses with only Moinak Ghosh, in case you'd like
 me to not discuss your thoughts with others.

 I am happy for you to share this as broadly as you like.


Thanks !

        - Garrett


 Thanks.

 -- Sriram
 Belenix: www.belenix.org


 [1] http://lists.debian.org/debian-legal/2010/09/msg1.html
 [2] 
 http://www.belenix.org/content/Proposal-use-rpm5-package-format-and-smart-package-manager
 [3] 
 

R: Why rpm5 and smart for Belenix

2011-09-03 Thread pinto.e...@gmail.com
Sorry for the top posting. I think @rpm5.org is glad of this. Just a, perhaps 
naive, question : What mean for a package manager to be more zfs-aware ? Thanks 
and best regards.
Messaggio originale
Da: Sriram Narayanan
Inviato:  03/09/2011, 18:59 
A: rpm-devel; rpm-users@rpm5.org
Oggetto: Why rpm5 and smart for Belenix


All:

For various reasons, we'd chosen to use rpm5 + smart for Belenix [1]

There was some recent development in the openindiana and illumos
communities, where Nexenta has reiterated that they would continue to
use their modified (or rather enhanced to be ZFS-aware) version of
dpkg + apt-get. I had an email exchange with Garrett, who is one of
the founding members of Illumos as well as a senior officer at
Nexenta.

The Belenix team will continue to use rpm5 and the smart package manager.

-- Sriram

[1] 
http://www.belenix.org/content/Proposal-use-rpm5-package-format-and-smart-package-manager

-- Forwarded message --
From: Sriram Narayanan sri...@belenix.org
Date: Sat, Sep 3, 2011 at 8:54 PM
Subject: Fwd: About dpkg and apt-get
To: Belenix Developers belenix-...@opensolaris.org


All:

Summary: I asked Garrett D'Amore of Nexenta/Illumos on Nexenta's
choice of using dpkg despite lack of clarity from Debian Legal. With
his permission, I'm forwarding his response to this mailing list.

My thoughts:
We should continue to use rpm5 and the smart package manager, given
the friendliness of the rpm5 team and the smart team with helping
others with adopting their technology in contrast to throwing
obstacles.


-- Ram


-- Forwarded message --
From: Sriram Narayanan sri...@belenix.org
Date: Sat, Sep 3, 2011 at 1:12 AM
Subject: Re: About dpkg and apt-get
To: Garrett D'Amore garr...@damore.org


On Sat, Sep 3, 2011 at 1:07 AM, Garrett D'Amore garr...@damore.org wrote:

 On Sep 2, 2011, at 11:31 AM, Sriram Narayanan wrote:

 Hi Garrett:

 It has been my impression that the Debian Legal community hasn't given
 a clear answer to whether they're fine with dpkg being used on a
 non-GPL kernel [1]

 I don't see that it matters.  The GPL is pretty clear here… the functional 
 boundary of the dpkg code is a self contained program, and the GPL has been 
 very clear that running GPL programs on proprietary kernels is fine.


 I also saw the IRC logs of the oi-meeting from earlier this week, and
 noted that you've mentioned that Nexenta will continue to use the dpkg
 format.

 For Belenix, we've been wary of getting into a mess at some future
 date, since we are a small group and don't have the wherewithal to get
 into an argument with Debian Legal. I therefore proposed that we use
 rpm5 + smart [2] and we're making some amount of progress on this. [3]
 [4]

 If possible, could you share with me your thoughts on using dpkg and
 how you feel that Nexenta would deal with disagreements with Debian
 Legal in the future ?

 I've had conversations with the Debian folks on this.  The challenge/debate 
 has always been the proprietary libc, not the kernel.  And it centers around 
 defining what is a derivative product, and the differences between derivation 
 and consolidation.

 The only guys who are fighting this are the guys with an axe to grind about 
 Linux.  In my estimation, and the estimation of at least one very well-known 
 lawyer familiar with this matter (i.e. my legal council), the interpretation 
 that would prevent using GPL user land software on a proprietary OS is 
 unreasonable, and clearly not the most logical interpretation of the GPL 
 language itself.

 The thing is for them to come after us, they would have to come after *every* 
 commercial non-GPL system that ships dpkg -- I think this includes Oracle and 
 Apple, and probably other companies as well.

 The *format* of the packages is irrelevant, its just the package manager 
 itself.

 At the end of the day, this is all FUD, and it was used to create a barrier 
 to our more broad participation in the Debian community, but my read of this 
 was that it was really done simply because we were not Linux, and that some 
 OS bigotry came into play and this was a way to keep us out.

 Its really silly, because the bone of contention was *not* a proprietary 
 libc, but one that has a copyleft as well with just slightly incompatible 
 terms with the GPL.  In fact, all reasonable open source advocates really 
 understand that the spirit of our libc is completely compatible with the 
 spirit of the GPL -- its just the guys with a political agenda that like to 
 spread licensing FUD.

 We have chosen to recognize the FUD for what it is, and ignore the concerns 
 of those spreading it.


Thanks for your response, Garrett. Overall, Moinak and I share the
same opinion with you on dpkg.

I also didn't have context earlier on libc, now thanks to you, I do.


 I'll share your responses with only Moinak Ghosh, in case you'd like
 me to not discuss your thoughts with others.

 I am happy for you to share this as broadly

Re: Why rpm5 and smart for Belenix

2011-09-03 Thread Jeff Johnson

On Sep 3, 2011, at 3:48 PM, pinto.e...@gmail.com wrote:

 Sorry for the top posting. I think @rpm5.org is glad of this. Just a, perhaps 
 naive, question : What mean for a package manager to be more zfs-aware ? 
 Thanks and best regards.

For starters:

ZFS has snapshots for --rollback.

And Solaris has SEEK_HOLE, useful if sparse files ever need to be packaged.

73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org