On Sat, Mar 31, 2007 at 10:19:47PM +0200, martin f krafft [EMAIL PROTECTED]
wrote:
also sprach Mike Hommey [EMAIL PROTECTED] [2007.03.31.1456 +0200]:
The idea is to automate the pseudo package creation...
Then, of course, it makes sense (even though it still feels like
a hack).
Also,
also sprach Mike Hommey [EMAIL PROTECTED] [2007.04.01.1000 +0200]:
Which is why i said it was necessary to filter the
build-dependencies ;)
I think I'll just shut up now. :)
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'`
On Wed, Mar 28, 2007, Mike Hommey wrote:
I got a stupid idea that may help solve this problem in a much simpler
way: Create a fake dummy package containing the strict minimum to get apt
do its job with the package dependencies.
That's an excellent and very inspiring idea; I was postponing
also sprach Loïc Minier [EMAIL PROTECTED] [2007.03.31.1247 +0200]:
On Wed, Mar 28, 2007, Mike Hommey wrote:
I got a stupid idea that may help solve this problem in a much
simpler way: Create a fake dummy package containing the strict
minimum to get apt do its job with the package
On Sat, Mar 31, 2007, martin f krafft wrote:
also sprach Loïc Minier [EMAIL PROTECTED] [2007.03.31.1247 +0200]:
On Wed, Mar 28, 2007, Mike Hommey wrote:
I got a stupid idea that may help solve this problem in a much
simpler way: Create a fake dummy package containing the strict
minimum
also sprach Loïc Minier [EMAIL PROTECTED] [2007.03.31.1257 +0200]:
Uh, I don't understand your remark at all; what does require a lot of
work?
Creating pseudo packages for all combinations of build dependencies?
Maybe I am also misunderstanding your proposal.
--
.''`. martin f. krafft
On Sat, Mar 31, 2007 at 02:50:00PM +0200, martin f krafft [EMAIL PROTECTED]
wrote:
also sprach Loïc Minier [EMAIL PROTECTED] [2007.03.31.1257 +0200]:
Uh, I don't understand your remark at all; what does require a lot of
work?
Creating pseudo packages for all combinations of build
On Sat, Mar 31, 2007, martin f krafft wrote:
Creating pseudo packages for all combinations of build dependencies?
Maybe I am also misunderstanding your proposal.
Instead of trying to parse debian/control and install each build-dep
and satisfy each build conflict as currently in
also sprach Mike Hommey [EMAIL PROTECTED] [2007.03.31.1456 +0200]:
The idea is to automate the pseudo package creation...
Then, of course, it makes sense (even though it still feels like
a hack).
Also, note that there are certain build-dependency syntax constructs
that cannot be ported to
On Sun, Oct 22, 2006 at 02:27:13PM +0200, Loïc Minier [EMAIL PROTECTED] wrote:
severity 337015 normal
tags 337015 + patch
merge 337015 #390888
retitle 337015 Support for pulling stuff from experimental
stop
Hi folks,
I just saw you already discussed supporting experimental in
severity 337015 normal
tags 337015 + patch
merge 337015 #390888
retitle 337015 Support for pulling stuff from experimental
stop
Hi folks,
I just saw you already discussed supporting experimental in pbuilder; I
implemented some form of support in #390888. In short, it tries to
force
also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.11.02.1506 +0100]:
It is quite possible that apt-pinning is working against us.
I don't think build-dep resolver really takes much consideration
about experimental.
We could make apt-pinning work so that it will always
prefer experimental
Package: pbuilder
Version: 0.128
Severity: normal
I have a package which depends on a package which is in unstable and
experimental. It build-depends on the version in experimental, and my
pbuilder chroot has the experimental sources available to it, but
pbuilder fetches the package from
Hi,
I have a package which depends on a package which is in unstable and
experimental. It build-depends on the version in experimental, and my
pbuilder chroot has the experimental sources available to it, but
pbuilder fetches the package from unstable. Obviously at this point the
package
14 matches
Mail list logo
