Hi,
just as a reminder:
Roger Leigh rle...@codelibre.net (16/03/2011):
OK. I think this is the only known discrepancy between the two
resolvers. Given that we now routinely build using minimal clean
(cloned) chroots, they will behave identically in practice because
AFAICT: only
On Thu, Mar 17, 2011 at 08:31:13AM +0100, Cyril Brulebois wrote:
Hi,
just as a reminder:
Roger Leigh rle...@codelibre.net (16/03/2011):
OK. I think this is the only known discrepancy between the two
resolvers. Given that we now routinely build using minimal clean
(cloned) chroots,
On to, 2011-03-17 at 08:32 +, Roger Leigh wrote:
You can get the same effect with file chroots (tarball unpack). It's
not that slow providing your tarball is really minimal, and it works
on all architectures. I used this for the whole archive rebuild after
LVM snapshots oopsed and then
On Wed, Mar 16, 2011 at 01:07:19AM +0100, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net writes:
On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael
Peter Pentchev r...@ringlet.net writes:
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude
On Tue, Feb 22, 2011 at 03:53:08PM -0800, Russ Allbery wrote:
Julien Cristau jcris...@debian.org writes:
I'm still not sure how 'Build-Depends: foo [i386] | bar [amd64]'
would make sense (as opposed to making it an 'and').
They're equivalent, so I would view it as intended for human
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude sbuild
resolvers to strip the alternatives (after arch reduction), which
will make them behave pretty much
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude sbuild
resolvers to strip the alternatives
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude sbuild
resolvers to strip the alternatives
On Wed, Feb 23, 2011 at 11:30:05AM +, Roger Leigh wrote:
I've now implemented this with the attached patch. If you are happy
with this behaviour, I'll commit it. Those six lines are equivalent
to about 300 in the internal resolver! With this change made, would
you be OK to consider
On Wed, Feb 23, 2011 at 12:27:00PM +0200, Peter Pentchev wrote:
Hi, and apologies in advance if this is a stupid question or if it has
already been discussed :)
Is it possible that this should lead to problems with further levels of
package dependencies? E.g. something like that for two
On Wed, Feb 23, 2011 at 12:27:00PM +0200, Peter Pentchev wrote:
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get
On Wed, Feb 23, 2011 at 11:30:05 +, Roger Leigh wrote:
+# Should the dependency resolve use alternatives in Build-Depends and
+# Build-Depends-Indep? By default, only the first alternative will be
+# used; all other alternatives will be removed. Note that this does
+# not include
On Tue, Feb 22, 2011 at 10:13:19PM +0100, gregor herrmann wrote:
On Tue, 22 Feb 2011 17:08:18 +, Roger Leigh wrote:
· Standard alternative use in the form concrete|virtual, as used for
normal deps on virtual packages. Is this sensible?
· Architecture-specific dependencies
·
On Tue, Feb 22, 2011 at 10:21:24PM +0100, Bill Allombert wrote:
On Tue, Feb 22, 2011 at 06:49:21PM +, Ian Jackson wrote:
Roger Leigh writes (Re: re buildd's resolver and package's build deps):
I agree that these do serve a useful purpose for these uses, and that
ease of reuse
On Tue, Feb 22, 2011 at 22:40:52 +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude sbuild
resolvers to strip the alternatives (after arch reduction), which
will make them behave pretty much
On Wed, Feb 23, 2011 at 12:05:28AM +0100, Julien Cristau wrote:
On Tue, Feb 22, 2011 at 22:40:52 +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude sbuild
resolvers to strip the alternatives
On Tue, 22 Feb 2011 22:28:05 +, Roger Leigh wrote:
perl (= 5.10) | libmodule-build-perl
Could you please explain what's pointless and/or broken about that
one?
(Except that it's old since even lenny has 5.10.0.
Yes, that's exactly the reason. Because the perl (= 5.10) is
On Tue, Feb 22, 2011 at 23:26:27 +, Roger Leigh wrote:
On Wed, Feb 23, 2011 at 12:05:28AM +0100, Julien Cristau wrote:
On Tue, Feb 22, 2011 at 22:40:52 +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get
Julien Cristau jcris...@debian.org writes:
I'm still not sure how 'Build-Depends: foo [i386] | bar [amd64]'
would make sense (as opposed to making it an 'and').
They're equivalent, so I would view it as intended for human readers, not
for computers.
In other words, I see a Build-Depends of:
20 matches
Mail list logo
