Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 10, 2013 at 10:31 AM, Aron Xu a...@debian.org wrote: On Wed, Apr 10, 2013 at 1:55 PM, Vincent Cheng vincentc1...@gmail.com wrote: Just for the record, here are some source packages (taken directly from latest pkg-nvidia git) for your convenience: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/primus_0~20130225-1.dsc bumblebee has been uploaded, but I still have questions about primus. primus has Recommends: primus-libs-ia32 [amd64], this means by default it will pull in some dependency if the users have i386 added to his architecture list. I doubt this is desirable for all cases, users should just install primus-libs:i386 when he needs to run 32bit applications, but not automated by the package manager in such a way? A nice error message indicating that needing a 32bit version of primus-libs would be sufficient to guide the user to install, IMHO. What do you think? Upstream wants to keep that (indeed, I wasn't even planning on including a primus-libs-ia32 package until upstream asked me to re-consider [1]). I acknowledge that this isn't pretty, but I understand upstream's rationale, i.e. that running 32-bit applications with primus is a common enough use case (wine) that we'd want to just push this to end-users by default. And AFAIK there currently is no nice error message for users who try to run a 32-bit application through primus without having installed primus-libs:i386 (unless you consider segfaults to be nice). Is there anything in Policy that would forbid this approach? (I can't think of any I'm not going to insist on keeping that recommends if you revert it (i.e. downgrade to suggests?), but can you please try to convince upstream first in that pull request (again, see [1]), if only for the sake of minimizing the diff between Debian and upstream's PPA and to maintain a healthy relationship with upstream (after making an effort to communicate with upstream, agreeing with their changes, and then just silently reverting the changes in the end anyways?). Thanks! Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10#issuecomment-15251004 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 10, 2013 at 1:55 PM, Vincent Cheng vincentc1...@gmail.com wrote: Just for the record, here are some source packages (taken directly from latest pkg-nvidia git) for your convenience: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/primus_0~20130225-1.dsc bumblebee has been uploaded, but I still have questions about primus. primus has Recommends: primus-libs-ia32 [amd64], this means by default it will pull in some dependency if the users have i386 added to his architecture list. I doubt this is desirable for all cases, users should just install primus-libs:i386 when he needs to run 32bit applications, but not automated by the package manager in such a way? A nice error message indicating that needing a 32bit version of primus-libs would be sufficient to guide the user to install, IMHO. What do you think? -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Thu, Apr 4, 2013 at 5:22 PM, Vincent Cheng vincentc1...@gmail.com wrote: On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. Do you think it's time to upload bumblebee? As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. I guess yes? Don't know other people's opinion. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
First off, sorry for the slow replies lately... On Tue, Apr 9, 2013 at 9:03 AM, Aron Xu a...@debian.org wrote: On Thu, Apr 4, 2013 at 5:22 PM, Vincent Cheng vincentc1...@gmail.com wrote: On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. Do you think it's time to upload bumblebee? I can now build bumblebee and primus again, but I can't get optirun -b primus to work properly with the latest packages from git, for some reason. Have you given those packages a try for yourself yet? I'm unsure if it's an issue on my end, or something that's expected by upstream right now. Upstream says that Rebasing for Bumblebee is less a good idea, however it's needed to be able to package it using the current packaging scripts [1], so I think that they're aware that the latest code from git is not so stable and we probably shouldn't upload it as is... We could also just revert my latest commits in bumblebee + primus git and just upload packages prior to the removal of primusrun. That'll mean that we'll have to carry primus-nvidia as a transitional package in the future, however. It's either this, or we wait until bumblebee 3.2 + primus get released with upstream's current issues sorted out. Any thoughts? As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. I guess yes? Don't know other people's opinion. It's a minor issue either way. /me shrugs Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just for the record, here are some source packages (taken directly from latest pkg-nvidia git) for your convenience: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/primus_0~20130225-1.dsc They're targeted for experimental, since bbswitch is only available via experimental, and I think it's best to wait for upstream to sort out the few issues remaining before uploading the yet-to-be-released bumblebee 3.2 + latest primus git to unstable. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/issues/11 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just a quick followup... On Mon, Apr 1, 2013 at 3:57 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). Upstream decided to drop the preinst file (which I was hoping for too), so the above change is no longer relevant anymore. I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P There's been quite a restructuring of the primus packaging lately, done by upstream; primus now queries the bumblebee daemon when it comes to picking nouveau/nvidia, instead of relying on environment variables set in primusrun, so we can now drop primus-nvidia, the duplicate primusrun scripts, and the maintainer scripts / use of the alternatives system (i.e. simplifies things a _lot_). However that also depends on a few changes to bumblebee as well. Hence, would you be willing to upload the latest bumblebee + primus code from upstream's git repos (rather than the current stable bumblebee 3.1 release)? (fwiw primus has never really seen a formal 'stable' release, so it doesn't really matter for primus) As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... There's also the issue that Nvidia Optimus is a feature included only with Intel+Nvidia AFAIK, hence bbswitch+bumblebee+primus is really only useful on i386 and amd64 anyways. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 3, 2013 at 6:45 PM, Vincent Cheng vincentc1...@gmail.com wrote: Just a quick followup... On Mon, Apr 1, 2013 at 3:57 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). Upstream decided to drop the preinst file (which I was hoping for too), so the above change is no longer relevant anymore. Good to know. I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P There's been quite a restructuring of the primus packaging lately, done by upstream; primus now queries the bumblebee daemon when it comes to picking nouveau/nvidia, instead of relying on environment variables set in primusrun, so we can now drop primus-nvidia, the duplicate primusrun scripts, and the maintainer scripts / use of the alternatives system (i.e. simplifies things a _lot_). However that also depends on a few changes to bumblebee as well. Hence, would you be willing to upload the latest bumblebee + primus code from upstream's git repos (rather than the current stable bumblebee 3.1 release)? (fwiw primus has never really seen a formal 'stable' release, so it doesn't really matter for primus) Then could you add it to Debian's git repo? As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) There's also the issue that Nvidia Optimus is a feature included only with Intel+Nvidia AFAIK, hence bbswitch+bumblebee+primus is really only useful on i386 and amd64 anyways. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/commit/f95d06289f3fac202a6888b2d36f639e527c3f96 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
[Whoops, hit reply instead of reply to all. It's gmail's fault.] On Sat, Mar 23, 2013 at 3:24 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Saturday 23 March 2013 03:02 PM, Vincent Cheng wrote: I see no harm in trying to make my package compatible with both Debian and Ubuntu, as long as the changes are not overly obtrusive and don't break anything in Debian. I'm actually of the opinion that it's best to minimize diffs between Debian and Ubuntu whenever possible, and I aim to do that with all the packages I maintain. Forcing derivatives to maintain deltas benefits nobody; we should encourage maintainers to forward as much work upstream as possible, and that goes for Ubuntu's relationship with Debian as well. I can understand the intent but then it will become a never ending story. Which derivative will you stop at? It ends at Debian and Ubuntu. The one major difference that is the root cause of all the Debian/Ubuntu-specific sections in bumblebee's packaging is how differently the proprietary nvidia driver is packaged (if that were fixed one day, there'd be no need for all the derivative specific stuff). No Debian/Ubuntu derivatives use a different packaging scheme for the Nvidia proprietary driver, except those who suggest directly downloading it from Nvidia's website (which we don't support). Sooner or later, your packaging rules end up being: if debian: elif derivative1: elif derivative2: elif . Combining the efforts should mean working on a common base. Not accommodating multiple bases this way. We are working on a common base. I'm working with upstream to merge all the Debian-specific changes, so that we can all pull from the same source each time there's a new upstream release without me having to put as much work to merge everything. The current packaging (which Aron started) was based off of upstream's PPA, and so far it looks like upstream is receptive to our changes, so we can continue basing our work off of upstream's PPA for future releases. Hence, less duplicate work for us in Debian. Diverging the packaging must have good reasons; at least it brings in the flexibility and the speed. In this case, the best example is the nvidia packaging. I still don't see convincing rationale for us to diverge the bumblebee + primus packaging from the work that upstream have done, or to break compatibility between Debian and Ubuntu. Like I said in the previous email, I haven't seen a guideline on this topic. But from what I've observed in different teams, none of them package this way. I haven't seen any guidelines either. But I don't think I'm the only one who's actively trying to accomodate both Debian and Ubuntu; e.g. I've seen blog posts where DDs have demonstrated how to merge differences in Debian and Ubuntu in the packaging scripts (see Raphael Hertzog's explanation on how to generate different sets of dependencies for Debian and Ubuntu [1]), or e.g. the Ubuntu Games team folding into the Debian Games team to collaborate together (but to be fair, I don't think there was much of an Ubuntu Games team to begin with...). Regards, Vincent [1] http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Vincent,
There might be merits of following the Ubuntu + Debian route _today_.
Maybe. But for the project, I fail to see the benefits.
I do not see myself convinced to mix packaging decisions for 2 different
distributions with different intent.
Take a look at the Dependencies in bumblebee-nvidia:
Depends: ${shlibs:Depends}, ${misc:Depends}, bumblebee (=
${binary:Version}),
nvidia-glx | nvidia-304 | nvidia-304-updates | nvidia-experimental-304 |
nvidia-310 | nvidia-310-updates | nvidia-experimental-310 |
nvidia-313 | nvidia-313-updates | nvidia-experimental-313
Sure it won't break. But it is all bogus for Debian, for ever, to OR
depend on packages that are non-existent.
As a DD, my efforts are to keep the packaging simple and minimal, so
that it is easier for _all_ derivatives to consume it.
Collaboration should be on
* Uniform package names
* Sharing patches
* Sharing policies
On Saturday 23 March 2013 04:23 PM, Vincent Cheng wrote:
[Whoops, hit reply instead of reply to all. It's gmail's fault.]
On Sat, Mar 23, 2013 at 3:24 AM, Ritesh Raj Sarraf r...@researchut.com
wrote:
On Saturday 23 March 2013 03:02 PM, Vincent Cheng wrote:
I see no harm in trying to make my package compatible with both Debian
and Ubuntu, as long as the changes are not overly obtrusive and don't
break anything in Debian. I'm actually of the opinion that it's best
to minimize diffs between Debian and Ubuntu whenever possible, and I
aim to do that with all the packages I maintain. Forcing derivatives
to maintain deltas benefits nobody; we should encourage maintainers to
forward as much work upstream as possible, and that goes for Ubuntu's
relationship with Debian as well.
I can understand the intent but then it will become a never ending
story. Which derivative will you stop at?
It ends at Debian and Ubuntu. The one major difference that is the
root cause of all the Debian/Ubuntu-specific sections in bumblebee's
packaging is how differently the proprietary nvidia driver is packaged
(if that were fixed one day, there'd be no need for all the derivative
specific stuff). No Debian/Ubuntu derivatives use a different
packaging scheme for the Nvidia proprietary driver, except those who
suggest directly downloading it from Nvidia's website (which we don't
support).
Sooner or later, your packaging rules end up being:
if debian:
elif derivative1:
elif derivative2:
elif .
Combining the efforts should mean working on a common base. Not
accommodating multiple bases this way.
We are working on a common base. I'm working with upstream to merge
all the Debian-specific changes, so that we can all pull from the same
source each time there's a new upstream release without me having to
put as much work to merge everything. The current packaging (which
Aron started) was based off of upstream's PPA, and so far it looks
like upstream is receptive to our changes, so we can continue basing
our work off of upstream's PPA for future releases. Hence, less
duplicate work for us in Debian.
Diverging the packaging must have good reasons; at least it brings in
the flexibility and the speed. In this case, the best example is the
nvidia packaging.
I still don't see convincing rationale for us to diverge the bumblebee
+ primus packaging from the work that upstream have done, or to break
compatibility between Debian and Ubuntu.
Like I said in the previous email, I haven't seen a guideline on this
topic. But from what I've observed in different teams, none of them
package this way.
I haven't seen any guidelines either. But I don't think I'm the only
one who's actively trying to accomodate both Debian and Ubuntu; e.g.
I've seen blog posts where DDs have demonstrated how to merge
differences in Debian and Ubuntu in the packaging scripts (see Raphael
Hertzog's explanation on how to generate different sets of
dependencies for Debian and Ubuntu [1]), or e.g. the Ubuntu Games team
folding into the Debian Games team to collaborate together (but to be
fair, I don't think there was much of an Ubuntu Games team to begin
with...).
Regards,
Vincent
[1]
http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
signature.asc
Description: OpenPGP digital signature
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Hi Ritesh, Vincent, I've cut off quotes as my reply does not apply to specific sentences... I agree that keeping a package simple have benefits, but I don't think making our life harder is a good reason to cut down such stuff. Our current packaging are largely based on upstream's efforts, and we have to agree that upstream consider both Debian and Ubuntu are important. We'd like to have a good relation with upstream, and actually we have friends who use these packages on both Debian and Ubuntu, so if we just cut down the compatibility stuff then we must deal with both Debian and Ubuntu to keep everyone happy, or we get hated. The differences between nvidia packaging isn't likely to change in a short time base on my understanding, so it's not neat to have a so long list in Depends/Recommends, and yes I agree it looks awful but we have no better choice to make everyone happy and keep the work load as less as it can be. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Saturday 23 March 2013 06:13 PM, Aron Xu wrote: I've cut off quotes as my reply does not apply to specific sentences... I agree that keeping a package simple have benefits, but I don't think making our life harder is a good reason to cut down such stuff. Our current packaging are largely based on upstream's efforts, and we have to agree that upstream consider both Debian and Ubuntu are important. We'd like to have a good relation with upstream, and actually we have friends who use these packages on both Debian and Ubuntu, so if we just cut down the compatibility stuff then we must deal with both Debian and Ubuntu to keep everyone happy, or we get hated. The differences between nvidia packaging isn't likely to change in a short time base on my understanding, so it's not neat to have a so long list in Depends/Recommends, and yes I agree it looks awful but we have no better choice to make everyone happy and keep the work load as less as it can be. As much as I want and will use bumblebee, I do not agree with the justification. Let's just disagree. :-) You sponsor the packages bumblebee and primus so that it gets in the queue. Thanks, Ritesh - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCgAGBQJRTeHxAAoJEKY6WKPy4XVpLHwQAIGphJa1Q5SKCug1Y3ob9Wls Rb0VEpZ68WRGn9ILd3mDH7jgsmU5VNZShC3jEQIGT012m6Jdh8U09w+NFd8ppEOc fOWo2cbRlQiioqELbLzwgDECIp0Z3TkkGwg8F2EoTZ24ikUXerDxwdYm3zQ+fpEo ISSBPJI2CSdXo9lZ+wjme35uVQUeYowImVoimPo2g0PS/zrrwT42c3rzmX91yFKb qLyubxN153QTycuOIiUHZ7h8WH4M9A58sW0DfOGLf2iYICKszXVAKfI8kv3Q46er x+VymC+PmKwmW4jHLm7gFtDVeGG9eXCRnwQQwCzQi/B5yZPB+4ZrbXCnOZ18cCFh hpo359GbJvxJd2sxwfD+WRgWOKwr+BQnqG8KFPEkm7ASFNBrnpkq7IZiGZ2FLbrz XhTQa320OO10wSm6oftD689bSZ/FgmWwQbbpgZBegPtqYqVpz7Crb2D2+qHOexug qHFf7JbGYjFRVYOSV21VtqBK8bXqtHDnK/E3vILS4xvYGjPBWla4i2CzNYjfAr9I yH5SQWW8q3UOLPmQHCKGZ7IJjJjbS5NYp8i9pyh5UBE0z6e0tiDhxqZ9YqmUmrHk AqSEtPE6V/OGRe+ZfkKvHZ1V5HpT0KHwNSEpaAqtxoIaRSEGn5E3n9MglbuMjBcU JNSAuYUSEwAZ/XNcwEtv =KRJ5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Hi, On Sat, Mar 23, 2013 at 10:10 AM, Ritesh Raj Sarraf r...@researchut.com wrote: As much as I want and will use bumblebee, I do not agree with the justification. Let's just disagree. :-) You sponsor the packages bumblebee and primus so that it gets in the queue. Fair enough. Regardless, thanks for taking the time to review and upload bbswitch! You're welcome to work on the bbswitch/bumblebee/primus packaging if you still want to, but I ask that you do not revert the changes that I've made for compatibility with Ubuntu (or at least, not without any consensus first). Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
