Tanguy Ortolo writes:
> Goswin von Brederlow, 2012-02-09 15:02+0100:
>> Again I don't see how the situation would be different with depends
>> instead of breaks. In both cases it is impossible to install a
>> mismatching set of versions.
>
> Well, with
> Package: xul-ext-adblock-plus
> De
Goswin von Brederlow, 2012-02-09 15:02+0100:
> Again I don't see how the situation would be different with depends
> instead of breaks. In both cases it is impossible to install a
> mismatching set of versions.
Well, with
Package: xul-ext-adblock-plus
Depends: iceweasel (>= 3.6.13, << 12.0
Tanguy Ortolo writes:
> Goswin von Brederlow, 2012-02-09 11:14+0100:
>> Why does it remove it? Or rather in which situations? A simple "upgrade"
>> or "dist-upgrade" should keep back the package rather than remove
>> iceape. Obviously if you force the issue it will remove iceape but that
>> then
Goswin von Brederlow, 2012-02-09 11:14+0100:
> Tanguy Ortolo writes:
>> While this is sufficient for most cases, it does not cover one
>> interesting case: a dependencies on a range of versions. For instance:
>> Package: xul-ext-adblock-plus
>> Depends: iceweasel (>= 3.6.13, << 12.0~a1+) |
Tanguy Ortolo writes:
> Packages can currenctly declared dependencies on specific versions of
> other packages, with simple relations: <<, <=, =, >= and >>. For
> instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | â¦
>
> While this is sufficien
Tanguy Ortolo wrote:
> Packages can currenctly declared dependencies on specific versions of
> other packages, with simple relations: <<, <=, =, >= and >>. For
> instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
>
> While this is sufficient fo
On Thu, Feb 02, 2012 at 12:10:17PM +0100, Cyril Brulebois wrote:
> Mike Hommey (02/02/2012):
> > As discussed on irc, if you instead do iceweasel-api-3.6, iceweasel-api-4.0,
> > etc. you end up having crazy dependencies like:
> > Depends: iceweasel-api-3.6 | iceweasel-api-4.0 | iceweasel-api-5.0 |
Mike Hommey (02/02/2012):
> As discussed on irc, if you instead do iceweasel-api-3.6, iceweasel-api-4.0,
> etc. you end up having crazy dependencies like:
> Depends: iceweasel-api-3.6 | iceweasel-api-4.0 | iceweasel-api-5.0 |
> iceweasel-api-6.0 | ... | iceweasel-api-11.0 | iceape-api-2.1 |
> icea
On Thu, Feb 02, 2012 at 11:33:01AM +0100, Mike Hommey wrote:
> On Thu, Feb 02, 2012 at 11:14:43AM +0100, Alexander Reichle-Schmehl wrote:
> > Hi!
> >
> > Am 02.02.2012 10:54, schrieb Tanguy Ortolo:
> > > Packages can currenctly declared dependencies on specific versions of
> > > other packages, wi
On Thu, Feb 02, 2012 at 11:14:43AM +0100, Alexander Reichle-Schmehl wrote:
> Hi!
>
> Am 02.02.2012 10:54, schrieb Tanguy Ortolo:
> > Packages can currenctly declared dependencies on specific versions of
> > other packages, with simple relations: <<, <=, =, >= and >>. For
> > instance:
> > Pack
Hi!
Am 02.02.2012 10:54, schrieb Tanguy Ortolo:
> Packages can currenctly declared dependencies on specific versions of
> other packages, with simple relations: <<, <=, =, >= and >>. For
> instance:
> Package: xul-ext-adblock-plus
> Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
>
>
Packages can currenctly declared dependencies on specific versions of
other packages, with simple relations: <<, <=, =, >= and >>. For
instance:
Package: xul-ext-adblock-plus
Depends: iceweasel (>= 3.6.13) | iceape (>= 2.1) | …
While this is sufficient for most cases, it does not cover one
Hi,
On Tue, Oct 07, 2003 at 05:03:19AM +1000, Anthony Towns wrote:
> On Sat, Oct 04, 2003 at 01:46:08AM +0200, Nicolas Boullis wrote:
> > Moreover, that does not answer to my real question: is there a good
> > reason not to implement such an extended syntax for versionned
> > relationships.
>
On Sat, Oct 04, 2003 at 01:46:08AM +0200, Nicolas Boullis wrote:
> Moreover, that does not answer to my real question: is there a good
> reason not to implement such an extended syntax for versionned
> relationships.
Probably not; but there needs to be a good reason to do it. It has to
be imple
On Fri, Oct 03, 2003 at 04:06:42PM -0400, Daniel Jacobowitz wrote:
> The best extant solution to this is just to Conflicts: foo (<= B).
> Forcing an upgrade isn't such a bad thing...
It could be a bad thing if it means upgrading a stable package to
unstable.
The stable version of the package mig
(Sorry Daniel for first sending this e-mail to you only by mistake.)
Hi,
On Fri, Oct 03, 2003 at 04:06:42PM -0400, Daniel Jacobowitz wrote:
> On Fri, Oct 03, 2003 at 09:55:09PM +0200, Nicolas Boullis wrote:
> > Hi,
> >
> > On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote:
On Fri, Oct 03, 2003 at 09:55:09PM +0200, Nicolas Boullis wrote:
> Hi,
>
> On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote:
>
> > > So I'd like my package to conflict with versions A to B of foo. I tried
> > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, a
Hi,
On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote:
> > So I'd like my package to conflict with versions A to B of foo. I tried
> > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared,
> > it does not work since it now conflicts both with all versio
Nicolas Boullis <[EMAIL PROTECTED]> writes:
> Hi,
>
> One package of mine needs to conflict with a few consecutive versions
> of a package. Let's say that the package foo introduced a feature that
> conflicts with my package in version A and removed it in version B.
>
> So I'd like my package to
Hi,
One package of mine needs to conflict with a few consecutive versions
of a package. Let's say that the package foo introduced a feature that
conflicts with my package in version A and removed it in version B.
So I'd like my package to conflict with versions A to B of foo. I tried
to specif
20 matches
Mail list logo
