Re: ranting vs bug filing (Re: potential MBF: first alternate depends not available in main
Holger Levsen hol...@layer-acht.org writes: Hi, this is not particulary about unrar or Goswin... On Samstag, 19. März 2011, Goswin von Brederlow wrote: No, I truely mean that unrar-free is practically useless. The stoneage rar formats it suports have not been in general use for many years. http://bugs.debian.org/src:unrar shows me two unrelated bugs, none stating it's useless. I wonder why people rant here about bugs, instead of filing them in the appropriate places. Ranting on -devel doesn't change things. (Sometimes its useful to make people aware, yes. But then, the next step is something else than ranting again.) cheers, Holger And don't forget: One mans useless piece of code is another mans holy grail. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxkmb4o2.fsf@frosties.localnet
ranting vs bug filing (Re: potential MBF: first alternate depends not available in main
Hi, this is not particulary about unrar or Goswin... On Samstag, 19. März 2011, Goswin von Brederlow wrote: No, I truely mean that unrar-free is practically useless. The stoneage rar formats it suports have not been in general use for many years. http://bugs.debian.org/src:unrar shows me two unrelated bugs, none stating it's useless. I wonder why people rant here about bugs, instead of filing them in the appropriate places. Ranting on -devel doesn't change things. (Sometimes its useful to make people aware, yes. But then, the next step is something else than ranting again.) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: potential MBF: first alternate depends not available in main
Bernhard R. Link brl...@debian.org writes: * Goswin von Brederlow goswin-...@web.de [110318 14:38]: And as long as it works I see no reason why a maintainer should not be allowed to put the non-free dep first in alternatives if there is a good reason. Debian makes some promises to users. Suprisingly getting non-free software installed is definitely nothing a maintainer alone should be able to decide. Like say: In 10+ years I have never ever seen a single rar file unrar-free could unpack but thousands that needed unrar/rar. If that was true then unrar-free should be dropped and everything depending on it be removed, too, or moved to contrib. Or did you want to say only unrar-free could unpack? Bernhard R. Link P.S: This whole discussion about rar makes me so nostalgic about the BBS times and the early 90ties. No, I truely mean that unrar-free is practically useless. The stoneage rar formats it suports have not been in general use for many years. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5a2j4y9.fsf@frosties.localnet
Re: potential MBF: first alternate depends not available in main
* Goswin von Brederlow goswin-...@web.de [110317 22:10]: My metric here is clearly the functionality for the user. Being able to modify it or get help with the package (which needs people being able and willing to look at the source and fix problems) is a very important part of functionality of the user. If not having free (as in speech) source is a problem then do not add non-free to your sources.list. That metric should not decide the order of depends. Just because there is one package confining what you do needs to be installed for whatever reason you no longer have a right to get helpful packages? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318104747.ga28...@pcpool00.mathematik.uni-freiburg.de
Re: potential MBF: first alternate depends not available in main
Bernhard R. Link brl...@debian.org wrote: * Goswin von Brederlow goswin-...@web.de [110317 22:10]: My metric here is clearly the functionality for the user. Being able to modify it or get help with the package (which needs people being able and willing to look at the source and fix problems) is a very important part of functionality of the user. If not having free (as in speech) source is a problem then do not add non-free to your sources.list. That metric should not decide the order of depends. Just because there is one package confining what you do needs to be installed for whatever reason you no longer have a right to get helpful packages? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318104747.ga28...@pcpool00.mathematik.uni-freiburg.de Not at all, but we should trust maintainers to use their judgement on this and not enforce a one size fits all policy across the project. Scott K
Re: potential MBF: first alternate depends not available in main
Bernhard R. Link brl...@debian.org writes: * Goswin von Brederlow goswin-...@web.de [110317 22:10]: My metric here is clearly the functionality for the user. Being able to modify it or get help with the package (which needs people being able and willing to look at the source and fix problems) is a very important part of functionality of the user. Frankly most users don't think ahead like that. They just want it to work. If it works they are happy. Unrar-free doesn't work, non-free unrar works. And as long as it works they really don't care. And as long as it works I see no reason why a maintainer should not be allowed to put the non-free dep first in alternatives if there is a good reason. Like say: In 10+ years I have never ever seen a single rar file unrar-free could unpack but thousands that needed unrar/rar. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxkstuql.fsf@frosties.localnet
Re: potential MBF: first alternate depends not available in main
* Goswin von Brederlow goswin-...@web.de [110318 14:38]: And as long as it works I see no reason why a maintainer should not be allowed to put the non-free dep first in alternatives if there is a good reason. Debian makes some promises to users. Suprisingly getting non-free software installed is definitely nothing a maintainer alone should be able to decide. Like say: In 10+ years I have never ever seen a single rar file unrar-free could unpack but thousands that needed unrar/rar. If that was true then unrar-free should be dropped and everything depending on it be removed, too, or moved to contrib. Or did you want to say only unrar-free could unpack? Bernhard R. Link P.S: This whole discussion about rar makes me so nostalgic about the BBS times and the early 90ties. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318141049.ga29...@pcpool00.mathematik.uni-freiburg.de
Re: potential MBF: first alternate depends not available in main
On Friday, March 18, 2011 10:10:49 am Bernhard R. Link wrote: * Goswin von Brederlow goswin-...@web.de [110318 14:38]: And as long as it works I see no reason why a maintainer should not be allowed to put the non-free dep first in alternatives if there is a good reason. Debian makes some promises to users. Suprisingly getting non-free software installed is definitely nothing a maintainer alone should be able to decide. Since they would have had to enable non-free, suprise would not be an appropriate reaction. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103181029.24107.deb...@kitterman.com
Re: potential MBF: first alternate depends not available in main
On Fri, Mar 18, 2011 at 3:10 PM, Bernhard R. Link brl...@debian.org wrote: Like say: In 10+ years I have never ever seen a single rar file unrar-free could unpack but thousands that needed unrar/rar. If that was true then unrar-free should be dropped and everything depending on it be removed, too, or moved to contrib. It probably should. -- Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim0yn36fk4s7bx1doqv78fjaotncc_jahrjj...@mail.gmail.com
Re: potential MBF: first alternate depends not available in main
Le vendredi 18 mars 2011 à 15:35 +0100, Olaf van der Spek a écrit : On Fri, Mar 18, 2011 at 3:10 PM, Bernhard R. Link brl...@debian.org wrote: Like say: In 10+ years I have never ever seen a single rar file unrar-free could unpack but thousands that needed unrar/rar. If that was true then unrar-free should be dropped and everything depending on it be removed, too, or moved to contrib. It probably should. Agreed. In its current state, the free version is a useless piece of junk. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1300459068.18745.188.camel@meh
Re: potential MBF: first alternate depends not available in main
* Scott Kitterman deb...@kitterman.com [110318 15:30]: Since they would have had to enable non-free, suprise would not be an appropriate reaction. Again, just because they had to enable non-free does not mean it should change the semantics of anything else. Non-free is not there for some hypothetical non-free junkie but for users who require the use of works that do not conform to the Debian Free Software Guidelines. If someone looks at a package with apt-cache show or at packages.debian.org and sees no non-free or contrib in that and they get non-free software installed by installing it with say apt-get they have every right to be suprised. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318211932.ga32...@pcpool00.mathematik.uni-freiburg.de
Re: potential MBF: first alternate depends not available in main
Bernhard R. Link brl...@debian.org writes: * Goswin von Brederlow goswin-...@web.de [110316 01:24]: I disagree. If non-free has a superior implementation of a package and the user has non-free configured then it should prefer the non-free package. Superiority is always a question of what metrics you start with. Not being able to fix bugs because of missing source code or missing licenses gives a very strong push into inferiority, at least it should for Debian users. Bernhard R. Link My metric here is clearly the functionality for the user. If not having free (as in speech) source is a problem then do not add non-free to your sources.list. That metric should not decide the order of depends. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjul8nf3.fsf@frosties.localnet
Re: potential MBF: first alternate depends not available in main
* Goswin von Brederlow goswin-...@web.de [110316 01:24]: I disagree. If non-free has a superior implementation of a package and the user has non-free configured then it should prefer the non-free package. Superiority is always a question of what metrics you start with. Not being able to fix bugs because of missing source code or missing licenses gives a very strong push into inferiority, at least it should for Debian users. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110316093459.gb19...@pcpool00.mathematik.uni-freiburg.de
Re: potential MBF: first alternate depends not available in main
Emilio Pozuelo Monfort po...@debian.org writes: On 02/03/11 04:24, Scott Kitterman wrote: It seems to me not worth a mass bug filing. This doesn't seem like something that would affect user's systems. Is there a rationale for imposing this ordering other than puiparts can't deal with it? If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Cheers, Emilio I disagree. If non-free has a superior implementation of a package and the user has non-free configured then it should prefer the non-free package. In the case of rar the free version, last I checked, could basicaly handle none of the rar files in use because only the stoneage rar formats were supported. Using the non-free version gives a huge improvement on the functionality. On the other hand, a case of Depends: xpdf | acroread (I had to come up with something :) should probably stay that way. For 90+% use cases xpdf is sufficient. I feel it should be left up to the maintainer which order to use with a recommendation to list main packages first unless there is a good reason why non-free should be prefered. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwqnvror.fsf@frosties.localnet
Re: potential MBF: first alternate depends not available in main
Mike O'Connor s...@debian.org writes: On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman deb...@kitterman.com wrote: On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote: If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? To me, this particualar case is one where we should definitely not be choosing a non-free version by default, as using the non-free version actually puts a financial burden on the user. Just becaause the user decided that he wants to enable non-free so he can install sun-java6, doesn't mean we should assume he is willing to buy a license for rar. I wonder what the default behaviour would be if you pin non-free below main. Would apt/aptitude/... then prefer the main alternatives because of the higher pin? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp1bvrgo.fsf@frosties.localnet
Re: potential MBF: first alternate depends not available in main
Hi, Carsten, thanks for the pointer to check-mir. I've briefly looked at the code and it seems it can be very easily converted to support Debian main too. On Freitag, 4. März 2011, Paul Wise wrote: Debian Policy section 2.2.1 already covers this: ...the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package. http://www.debian.org/doc/debian-policy/ch-archive.html#s-main So does that mean a depends on apache | apache2 is forbidden, as apache is not in main? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: potential MBF: first alternate depends not available in main
On Fri, Mar 4, 2011 at 7:09 PM, Holger Levsen hol...@layer-acht.org wrote: So does that mean a depends on apache | apache2 is forbidden, as apache is not in main? I guess so, unless apache2 provides apache. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=xbq+y7vt23yql15uu_hwdoaypdxwnnrqv2...@mail.gmail.com
Re: potential MBF: first alternate depends not available in main
* Paul Wise [2011-03-04 12:54 +0800]: On Thu, Mar 3, 2011 at 10:28 PM, Carsten Hey cars...@debian.org wrote: But, anyway, I believe that the first depends of an alternate depends relation should be available in main and propose to file bugs about this. Do you agree this warrants a mass bug filing? I couldn't find this written out in policy ... If the is a consensus, it could be added to the developer's reference or the policy. Debian Policy section 2.2.1 already covers this: ...the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package. http://www.debian.org/doc/debian-policy/ch-archive.html#s-main This can be read in different ways: * All of the alternatives must be in main. * The first alternative must be in main. * One of the alternatives must be in main. Before the Ubuntu main inclusion requirements had been clarified in January, they have at least once wrongly been read as All of There are many dependencies on, e.g., openjdk-6-jre | sun-java6-jre, in Debian which would violate policy if all of the alternatives would need to be in main. I hope we agree that the first mentioned way to read this section is not how the current policy should be interpreted and think that a clarification could improve the policy. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304121636.ga20...@furrball.stateful.de
Re: potential MBF: first alternate depends not available in main
* Carsten Hey cars...@debian.org [110304 06:17]: * Paul Wise [2011-03-04 12:54 +0800]: Debian Policy section 2.2.1 already covers this: ...the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package. http://www.debian.org/doc/debian-policy/ch-archive.html#s-main This can be read in different ways: * All of the alternatives must be in main. * The first alternative must be in main. * One of the alternatives must be in main. From an English language POV, the quote above (taken out of context) clearly forbids any alternative in a Depends or Recommends from being outside of main. Here is the quote with enough context to show that the intent was otherwise and that other interpretations are reasonable: ...the packages in main • must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) I am not a DD or an expert on policy, but I would interpret the parenthetical to be explanatory rather than normative. Here is a suggested wording to clarify the parenthetical: ...the packages in main • must not require a package outside of main for compilation or execution (thus, all declared Depends, Recommends, and Build-Depends relationships must be satisfiable with only packages in main) I will file a wishlist bug against policy if there are no objections. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304154535.ga3...@cleo.wdw
Re: potential MBF: first alternate depends not available in main
Marvin Renich m...@renich.org wrote: * Carsten Hey cars...@debian.org [110304 06:17]: * Paul Wise [2011-03-04 12:54 +0800]: Debian Policy section 2.2.1 already covers this: ...the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package. http://www.debian.org/doc/debian-policy/ch-archive.html#s-main This can be read in different ways: * All of the alternatives must be in main. * The first alternative must be in main. * One of the alternatives must be in main. From an English language POV, the quote above (taken out of context) clearly forbids any alternative in a Depends or Recommends from being outside of main. Here is the quote with enough context to show that the intent was otherwise and that other interpretations are reasonable: ...the packages in main • must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) I am not a DD or an expert on policy, but I would interpret the parenthetical to be explanatory rather than normative. Here is a suggested wording to clarify the parenthetical: ...the packages in main • must not require a package outside of main for compilation or execution (thus, all declared Depends, Recommends, and Build-Depends relationships must be satisfiable with only packages in main) I will file a wishlist bug against policy if there are no objections. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304154535.ga3...@cleo.wdw Seems reasonable to me. Scott K
Re: potential MBF: first alternate depends not available in main
* Scott Kitterman deb...@kitterman.com [110304 10:01]: Seems reasonable to me. Bug filed: #616462 ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304174703.ga3...@cleo.wdw
Re: potential MBF: first alternate depends not available in main
* Holger Levsen [2011-02-28 16:05 +0100]: piuparts in master-slave mode currently cannot test packages which first alternate depends is not available in main, ie the secvpn package depends on adduser, bc, ssh, ppp, timeout | coreutils (= 7.5-1), sudo and timeout is only available in lenny and etch, thus piuparts cannot test secvpn in squeeze, wheezy and sid. That's a bug in piuparts. Another popular example is a depends on apache | apache2... Martin Pitt implemented a script[1] that tests for a similar package relationship problem in Ubuntu main[2]: | All build and binary dependencies (including Recommends:) must be | satisfyable in main (i. e. the preferred alternative must be in main). But, anyway, I believe that the first depends of an alternate depends relation should be available in main and propose to file bugs about this. Do you agree this warrants a mass bug filing? I couldn't find this written out in policy ... If the is a consensus, it could be added to the developer's reference or the policy. Regards Carsten [1] http://www.piware.de/2011/01/new-tool-to-check-support-status-of-dependencies/ [2] https://wiki.ubuntu.com/UbuntuMainInclusionRequirements -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303142813.gb29...@furrball.stateful.de
Re: potential MBF: first alternate depends not available in main
On Thu, Mar 3, 2011 at 10:28 PM, Carsten Hey cars...@debian.org wrote: But, anyway, I believe that the first depends of an alternate depends relation should be available in main and propose to file bugs about this. Do you agree this warrants a mass bug filing? I couldn't find this written out in policy ... If the is a consensus, it could be added to the developer's reference or the policy. Debian Policy section 2.2.1 already covers this: ...the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package. http://www.debian.org/doc/debian-policy/ch-archive.html#s-main -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=zJ2+edUt+Qtp=WDfCu=eb4feinhyp_f5fs...@mail.gmail.com
Re: potential MBF: first alternate depends not available in main
On 02/03/11 04:24, Scott Kitterman wrote: It seems to me not worth a mass bug filing. This doesn't seem like something that would affect user's systems. Is there a rationale for imposing this ordering other than puiparts can't deal with it? If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e13aa.7070...@debian.org
Re: potential MBF: first alternate depends not available in main
On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfort po...@debian.org wrote: If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. non-free stuff shouldn't be in main depends at all IMO, even as an alternative. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktime83fp_akmnfb-0rgshdt731fpl8hlk_syk...@mail.gmail.com
Re: potential MBF: first alternate depends not available in main
Hi, On Mittwoch, 2. März 2011, Paul Wise wrote: non-free stuff shouldn't be in main depends at all IMO, even as an alternative. I (somewhat) agree. And I think non-existing stuff is worse than non-free... But, I can see how it can be useful (users, derivatives), thus I think it just shouldn't be the first alternative. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: potential MBF: first alternate depends not available in main
On Wed, Mar 02, 2011 at 11:51:01AM +0100, Holger Levsen wrote: Hi, On Mittwoch, 2. März 2011, Paul Wise wrote: non-free stuff shouldn't be in main depends at all IMO, even as an alternative. I (somewhat) agree. And I think non-existing stuff is worse than non-free... But, I can see how it can be useful (users, derivatives), thus I think it just shouldn't be the first alternative. +1 -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302105353.ga7...@ca.home.jhr-online.de
Re: potential MBF: first alternate depends not available in main
On 02/03/11 12:45, Paul Wise wrote: On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfortpo...@debian.org wrote: If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. non-free stuff shouldn't be in main depends at all IMO, even as an alternative. Then please state what you think should happen in the case pointed out by Emilio. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e2409.20...@debian.org
Re: potential MBF: first alternate depends not available in main
On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote: On 02/03/11 04:24, Scott Kitterman wrote: It seems to me not worth a mass bug filing. This doesn't seem like something that would affect user's systems. Is there a rationale for imposing this ordering other than puiparts can't deal with it? If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103020941.02177.deb...@kitterman.com
Re: potential MBF: first alternate depends not available in main
On Wed, Mar 02, 2011 at 09:41:00AM -0500, Scott Kitterman wrote: Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? Because packages not in Debian will be pulled in by packages in main automatically. And also because, for better or for worse, handling non-initial alternate dependencies is still very much of a crapshoot in Debian. Thus the first alternative will be the most likely to be installed in a variety of situations, and that should be something in main if possible. It avoids breakage in the situation where non-free and contrib are *not* in use, and it prioritizes the closure of main over the use of non-free software. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: potential MBF: first alternate depends not available in main
On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman deb...@kitterman.com wrote: On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote: If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? To me, this particualar case is one where we should definitely not be choosing a non-free version by default, as using the non-free version actually puts a financial burden on the user. Just becaause the user decided that he wants to enable non-free so he can install sun-java6, doesn't mean we should assume he is willing to buy a license for rar. pgpvrg0NpSmH2.pgp Description: PGP signature
Re: potential MBF: first alternate depends not available in main
On 02/03/11 14:41, Scott Kitterman wrote: On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote: On 02/03/11 04:24, Scott Kitterman wrote: It seems to me not worth a mass bug filing. This doesn't seem like something that would affect user's systems. Is there a rationale for imposing this ordering other than puiparts can't deal with it? If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? If the user has rar-nonfree installed, that would be fine, as the dependency would be satisfied. If he doesn't have it, then installing a package from main shouldn't install packages outside main, so we should prefer packages in main over those outside it. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e5e8b.2080...@debian.org
Re: potential MBF: first alternate depends not available in main
On Wed, Mar 02, 2011 at 09:58:02AM -0500, Mike O'Connor wrote: On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman deb...@kitterman.com wrote: On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote: If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. rar | rar-nonfree instead of the other way round. Why? If the user has made the choice to use non-free and the maintainer concludes that's a more technically capable solution for users that choose to use it, why should the project raise barriers to that choice? To me, this particualar case is one where we should definitely not be choosing a non-free version by default, as using the non-free version actually puts a financial burden on the user. Just becaause the user decided that he wants to enable non-free so he can install sun-java6, doesn't mean we should assume he is willing to buy a license for rar. Uhm? What choice are you talking about? There are three packages: rar (the compressor) unrar unrar-free The compressor comes with a 40 days test license and request payment after that period. Of course, in practice no one pays -- home users just ignore it, those for whom legality matters usually choice other compressors. On Debian, there is hardly every any reason to use rar, so any dependencies on it should probably be avoided. The two decompressors: unrar-free is useless for anything but unpacking some historical archives. You'd have to dig deep to find any it can actually handle. Depending or recommending it is thus pointless. unrar is what you need to unpack anything you can get today. Sadly, thanks to people ignoring the compressor's cost this format remains pretty popular and many tools depend/recommend/suggest unrar for a good reason. Too bad, I'm afraid that any recommendation for unrar-free is a bug since it does nothing good for the user and causes confusion. For example for .cbr, no files are compressed using rar2 as that format is newer than rar3. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302161229.ga3...@angband.pl
Re: potential MBF: first alternate depends not available in main
On 02/03/2011 16:13, Emilio Pozuelo Monfort wrote: If the user has rar-nonfree installed, that would be fine, as the dependency would be satisfied. If he doesn't have it, then installing a package from main shouldn't install packages outside main, so we should prefer packages in main over those outside it. If a user choices to enable other repository (such as the non-free section or even external repository), he can expect that these repository will be managed equally. Moreover, as for the unrar example, the non-main package is often better featured (but, of course, with a worst license) than the one in main (else, the non-main package would not even exits). So, installing them if the admin choices to use non-main repository seems the good thing to do by the package manager in this case. If a user uses only main, then he will never have a package installing a other one outside of main. If you want that a package from main do not install a package outside of main, you will have to fix several other problems (packages with a newer version in another enabled repository). But, in my opinion, this is a bad fight against the choice of the administrator... If a admin wants non-free (or another repo) only for one software (java, ...), he can use pinning to express this concern to the package manager. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6ec13c.5070...@free.fr
Re: potential MBF: first alternate depends not available in main
Holger Levsen writes (potential MBF: first alternate depends not available in main): piuparts in master-slave mode currently cannot test packages which first alternate depends is not available in main, ie the secvpn package depends on adduser, bc, ssh, ppp, timeout | coreutils (= 7.5-1), sudo and timeout is only available in lenny and etch, thus piuparts cannot test secvpn in squeeze, wheezy and sid. That's a bug in piuparts. Would it be possible to make piuparts cope by ignoring dependencies which are not available in the target suite ? That would make it easier to test against a different suite to the one intended, too. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19820.61423.343813.790...@chiark.greenend.org.uk
Re: potential MBF: first alternate depends not available in main
Hi Ian, On Dienstag, 1. März 2011, Ian Jackson wrote: Would it be possible to make piuparts cope by ignoring dependencies which are not available in the target suite ? sure - patches welcome ;-) But... that's not as easy as one would wish. Look at /piupartslib/dependencyparser.py and at the Package and PackagesDB classes from piupartslib/packagesdb.py... Actually, I think it's really hard to change the code to cope as it's also far from trivial to use another dependency parser, esp. for master-slave mode. But still, while this is definitly a bug in piuparts, what do you think about the topic in subject? That would make it easier to test against a different suite to the one intended, too. Why? A suite should be self contained. (Or, explicitly support other suites like security supports main.) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: potential MBF: first alternate depends not available in main
On Monday, February 28, 2011 10:05:22 am Holger Levsen wrote: Hi, piuparts in master-slave mode currently cannot test packages which first alternate depends is not available in main, ie the secvpn package depends on adduser, bc, ssh, ppp, timeout | coreutils (= 7.5-1), sudo and timeout is only available in lenny and etch, thus piuparts cannot test secvpn in squeeze, wheezy and sid. That's a bug in piuparts. Another popular example is a depends on apache | apache2... So I think it's also a bug in those packages, of which there are more then 100 but less than 200. (To my regret I have to admit there is another bug in piuparts and http://piuparts.debian.org/sid/state-dependency-does-not-exist.html lists a few packages incorrectly.) But, anyway, I believe that the first depends of an alternate depends relation should be available in main and propose to file bugs about this. Do you agree this warrants a mass bug filing? I couldn't find this written out in policy so these bugs would be wishlist, which probably would make them not warrant a mass bug filing... Comments? It seems to me not worth a mass bug filing. This doesn't seem like something that would affect user's systems. Is there a rationale for imposing this ordering other than puiparts can't deal with it? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103012324.24545.deb...@kitterman.com
potential MBF: first alternate depends not available in main
Hi, piuparts in master-slave mode currently cannot test packages which first alternate depends is not available in main, ie the secvpn package depends on adduser, bc, ssh, ppp, timeout | coreutils (= 7.5-1), sudo and timeout is only available in lenny and etch, thus piuparts cannot test secvpn in squeeze, wheezy and sid. That's a bug in piuparts. Another popular example is a depends on apache | apache2... So I think it's also a bug in those packages, of which there are more then 100 but less than 200. (To my regret I have to admit there is another bug in piuparts and http://piuparts.debian.org/sid/state-dependency-does-not-exist.html lists a few packages incorrectly.) But, anyway, I believe that the first depends of an alternate depends relation should be available in main and propose to file bugs about this. Do you agree this warrants a mass bug filing? I couldn't find this written out in policy so these bugs would be wishlist, which probably would make them not warrant a mass bug filing... Comments? cheers, Holger libbarby-ruby (Gunnar Wolf gwolf@debianorg) dependency libbarby-ruby18 is dependency-does-not-exist libgettext-rails-ruby (Gunnar Wolf gwolf@debianorg) dependency-does-not-exist libwill-paginate-ruby (Gunnar Wolf gwolf@debianorg) dependency-does-not-exist stage (Michael Janssen jamuraa@debianorg) dependency libstageplugin1 is dependency-does-not-exist secvpn (Bernd Schumacher berndschumacher@hpcom) gnuradio-apps (Bdale Garbee bdale@gagcom) dependency gnuradio-gpio is dependency-does-not-exist dependency gnuradio-pager is dependency-does-not-exist dependency gnuradio-sounder is dependency-does-not-exist dependency-does-not-exist dependency-does-not-exist dimp1 (Debian Horde Maintainers dependency imp4 is dependency-does-not-exist libfeedtools-ruby (Marc Dequ?nes (Duck) Duck@DuckCorporg) dependency-does-not-exist liblocale-rails-ruby (Gunnar Wolf gwolf@debianorg) dependency-does-not-exist librqrcode-ruby (Gunnar Wolf gwolf@debianorg) dependency librqrcode-ruby18 is dependency-does-not-exist libruby-extras (Paul van Tilburg paulvt@debianorg) dependency libruby18-extras is dependency-does-not-exist libwill-paginate-ruby18 (Gunnar Wolf gwolf@debianorg) dependency rails is dependency-does-not-exist libgettext-rails-ruby18 (Gunnar Wolf gwolf@debianorg) dependency rails is dependency-does-not-exist gpe-mininet (Neil Williams codehelp@debianorg) dependency gpe-conf is dependency-does-not-exist phoneui-apps (Debian freesmartphoneorg Team dependency phoneuid is dependency-does-not-exist libapache2-mod-suphp (Emmanuel Lacour elacour@home-dnnet) dependency suphp-common is dependency-does-not-exist redmine-plugin-botsfilter (J?r?my Lal kapouer@melixorg) dependency redmine is dependency-does-not-exist python-desktopcouch-records (David Paleino dapal@debianorg) dependency desktopcouch is dependency-does-not-exist libinsighttoolkit3-java (Debian Med Packaging Team dependency-does-not-exist syncbbdb (Chris Waters xtifr@debianorg) dependency pilot-manager is dependency-does-not-exist desktopcouch-tools (David Paleino dapal@debianorg) dependency desktopcouch is dependency-does-not-exist rails (Adam Majer adamm@zombinocom) dependency rails-ruby18 is dependency-does-not-exist libbarby-ruby18 (Gunnar Wolf gwolf@debianorg) dependency-does-not-exist librqrcode-ruby18 (Gunnar Wolf gwolf@debianorg) dependency rails is dependency-does-not-exist liblocale-rails-ruby18 (Gunnar Wolf gwolf@debianorg) dependency rails is dependency-does-not-exist librqrcode-ruby191 (Gunnar Wolf gwolf@debianorg) dependency rails is dependency-does-not-exist zope-ploneformgen (Debian/Ubuntu Zope Team dependency-does-not-exist gpe-appmgr (Neil Williams codehelp@debianorg) dependency gpe-conf is dependency-does-not-exist libgnuradio-usrp2-dev (Bdale Garbee bdale@gagcom) dependency-does-not-exist gnuradio-pager (Bdale Garbee bdale@gagcom) dependency-does-not-exist gnuradio-radio-astronomy (Bdale Garbee bdale@gagcom) dependency-does-not-exist gnuradio-utils (Bdale Garbee bdale@gagcom) dependency-does-not-exist dependency-does-not-exist ptex-jisfonts (OHURA Makoto ohura@debianorg) dependency ptex-bin is dependency-does-not-exist arc-colors (GNOME-Colors Packagers dependency arc-brave is dependency-does-not-exist dependency arc-dust is dependency-does-not-exist dependency arc-human is dependency-does-not-exist dependency
Re: potential MBF: first alternate depends not available in main
On 28/02/11 15:05, Holger Levsen wrote: So I think it's also a bug in those packages, of which there are more then 100 but less than 200 A dd-list would be nice. Thanks, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6bc4d4.2040...@debian.org
