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
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 Geissert wrote:
I disagree here.
Alternatives in build-* relationships
Hi,
Am Montag, den 28.02.2011, 19:12 + schrieb Roger Leigh:
Agreed. Note that we now support strict 'first-only' alternatives
handling with the 'apt' and 'aptitude' resolvers. See the notes for
0.60.0 and 0.60.1 pertaining to resolvers here:
On Sun, Mar 6, 2011 at 4:36 PM, Joachim Breitner nome...@debian.org wrote:
I have a bit a bad feeling about not being able to use alternatives in
build-depends. For example at the moment, we are renaming a self-hosting
compiler package from ghc6 to ghc. Previously, the dependency has been
on
Hi,
Am Sonntag, den 06.03.2011, 16:41 +0100 schrieb Olaf van der Spek:
On Sun, Mar 6, 2011 at 4:36 PM, Joachim Breitner nome...@debian.org wrote:
I have a bit a bad feeling about not being able to use alternatives in
build-depends. For example at the moment, we are renaming a self-hosting
On Mon, Feb 28, 2011 at 07:12:00PM +, Roger Leigh wrote:
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:
This is correct. I was thinking about drafting a patch for Policy
about this. Current Policy defines
Hi Roger,
On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact,
there's even an example in section 7.1.
This is correct.
Wouter Verhelst wou...@debian.org writes:
On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
· concrete|virtual
libgl1-mesa-dev | libgl-dev
libglu1-mesa-dev | libglu-dev
The nvidia GL libraries conflict with mesagl. If you use the non-free
nvidia driver, you cannot install
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 Geissert wrote:
I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact,
On Mon, Feb 28, 2011 at 07:12:00PM +, Roger Leigh wrote:
This was a pain when we changed the default inetd--every package
required updating. For others, e.g. mail-transport-agent, it's even
more painful (I thought an mta-default was proposed, similar to
virtual-policy above, but can't see
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 02/22/2011 06:08 PM, Roger Leigh wrote:
I agree that the documentation is sorely lacking in this regard.
It is, however, an unofficial and unwritten policy. The need for
this is fairly self-explanatory: we don't want builds to vary.
Taking one of php5's dependencies as an example:
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 Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
Hi everyone, Roger,
Roger Leigh has filed a few bug reports related to how the buildd's resolver
(either internal or any of the new ones: apt{,itude}) and I'm not sure I
quiet agree.
Let's take for example the one filed
Roger Leigh writes (Re: re buildd's resolver and package's build deps):
Taking one of php5's dependencies as an example:
libdb-dev (= 4.7) | libdb4.8-dev | libdb4.6-dev
This dependency permits building against no less than *three* different
Berkeley DB versions. Given
On Tue, Feb 22, 2011 at 05:21:17PM +, Ian Jackson wrote:
Roger Leigh writes (Re: re buildd's resolver and package's build deps):
Taking one of php5's dependencies as an example:
libdb-dev (= 4.7) | libdb4.8-dev | libdb4.6-dev
This dependency permits building against no less than
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 backporting and other types of porting are important.
However, there is no way to know which of those alternatives applies
to which suite
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
· Broken uses. Dependencies on multiple different libraries which will
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 backporting and other types of porting are important.
However
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
hi,
On Mon, 2011-02-21 at 19:42 -0600, Raphael Geissert wrote:
I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact,
there's even an example in section 7.1.
There's also no stated guarantee *anywhere* (including release policy) that
the package's
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:
[explicit BCC to Roger]
Hi everyone, Roger,
Roger Leigh has filed a few bug reports related to how the buildd's resolver
(either internal or any of the new ones: apt{,itude}) and I'm not sure I quiet
agree.
Let's take for example the one filed against php5 [#614413]:
[...]
Severity:
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will
39 matches
Mail list logo
