Holger Levsen 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://b
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
"Bernhard R. Link" writes:
> * Goswin von Brederlow [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-fr
* Scott Kitterman [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 ju
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 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
On Fri, Mar 18, 2011 at 3:10 PM, Bernhard R. Link 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 mo
On Friday, March 18, 2011 10:10:49 am Bernhard R. Link wrote:
> * Goswin von Brederlow [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
* Goswin von Brederlow [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 n
"Bernhard R. Link" writes:
> * Goswin von Brederlow [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 par
"Bernhard R. Link" wrote:
* Goswin von Brederlow [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 func
* Goswin von Brederlow [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 n
"Bernhard R. Link" writes:
> * Goswin von Brederlow [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.
>
* Goswin von Brederlow [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 m
Mike O'Connor writes:
> On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman
> 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 hav
Emilio Pozuelo Monfort 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
* Scott Kitterman [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.
Marvin Renich wrote:
* Carsten Hey [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.deb
* Carsten Hey [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/c
* Paul Wise [2011-03-04 12:54 +0800]:
> On Thu, Mar 3, 2011 at 10:28 PM, Carsten Hey 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
On Fri, Mar 4, 2011 at 7:09 PM, Holger Levsen 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
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"
On Thu, Mar 3, 2011 at 10:28 PM, Carsten Hey 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
>>
* 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 lenn
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 t
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
> 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 th
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 rationa
On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman 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" in
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 pack
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
On 02/03/11 12:45, Paul Wise wrote:
On Wed, Mar 2, 2011 at 5:53 PM, 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.
n
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...
>
> B
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
should
On Wed, Mar 2, 2011 at 5:53 PM, 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.
non-free stuff shouldn't be in main de
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 pack
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
> time
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 th
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
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? C
38 matches
Mail list logo
