Re: Bits from the experimental autobuilder team (or: For Those Who Care About Experimental...)
Wouter Verhelst [EMAIL PROTECTED] writes: [1] It might be possible to write an apt preferences file to fix this problem differently, but not doing that actually has its advantages, in that we force maintainers to actually know what experimental package versions they're build-depending on. I'm thinking more of extending the capabilities of apt itself for 2 cases: 1) apt-get install foo (= 1.2-3) or apt-get install foo=1.2-3 Sort the known versions of foo according to pin and version like now but then, instead of picking the top one, pick the first one fullfilling the version requirement. This could be foo=2.0-5. 2) apt-get install foo and foo Depends: bar (= 1.2-3) Install bar = 1.2-3 even if it is not the top candidate. This should be just like apt-get install foo bar (= 1.2-3) One exception (or configure option) might be that it refuses to downgrade or only uses pins over 100 or 500 or something. Or it won't install a package with a pin lower than the already installed package. Not sure what would be the most practical there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the experimental autobuilder team (or: For Those Who Care About Experimental...)
Goswin von Brederlow [EMAIL PROTECTED] wrote: I'm thinking more of extending the capabilities of apt itself for 2 cases: 1) apt-get install foo (= 1.2-3) or apt-get install foo=1.2-3 Sort the known versions of foo according to pin and version like now but then, instead of picking the top one, pick the first one fullfilling the version requirement. This could be foo=2.0-5. That sounds sensible. 2) apt-get install foo and foo Depends: bar (= 1.2-3) Install bar = 1.2-3 even if it is not the top candidate. This should be just like apt-get install foo bar (= 1.2-3) Without further precautions, this would make life harder for people who currently use pinning. If a package is broken, because it depends on stuff only in experimental, it would just install the experimental version, but I'd rather have a warning here. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bits from the experimental autobuilder team (or: For Those Who Care About Experimental...)
Frank Küster [EMAIL PROTECTED] wrote: Goswin von Brederlow [EMAIL PROTECTED] wrote: I'm thinking more of extending the capabilities of apt itself for 2 cases: 1) apt-get install foo (= 1.2-3) or apt-get install foo=1.2-3 Sort the known versions of foo according to pin and version like now but then, instead of picking the top one, pick the first one fullfilling the version requirement. This could be foo=2.0-5. That sounds sensible. 2) apt-get install foo and foo Depends: bar (= 1.2-3) Install bar = 1.2-3 even if it is not the top candidate. This should be just like apt-get install foo bar (= 1.2-3) Without further precautions, this would make life harder for people who currently use pinning. If a package is broken, because it depends on stuff only in experimental, it would just install the experimental version, but I'd rather have a warning here. Regards, Frank Install the necessary version even if it's not the top choice, but only if the priority is higher than a given threshold (say 50). Then normal users get experimental pinned at 1 as it is now, but the experimental autobuilders get experimental pinned at 51 using /etc/apt/preferences. --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures.
Re: Bits from the experimental autobuilder team (or: For Those Who Care About Experimental...)
On Tue, Apr 11, 2006 at 09:28:27PM +0200, Wouter Verhelst wrote: Hello World, As many of you undoubtedly know, experimental is autobuilt these days. ... However, it will only work if the build-dependencies are fully specified; i.e., if a package 'foo' in experimental requires another package in experimental (let's call that one 'bar'), and another package needs 'foo' from experimental to build, then just installing 'foo' from experimental isn't going to cut it; you would end up with a command line like apt-get install foo=experimental version, which would try to install the experimental version of foo with the unstable version of bar, and fail because of unmet versioned dependencies. The solution[1] to this problem lies in a different use of the build-depends field: we're hereby asking maintainers who upload to experimental, to make sure to fully specify their build-dependencies on experimental packages; not just the packages they directly depend on, but also the packages they indirectly, through other packages, depend on. Let me repeat that, because it's quite important: if you upload a package to experimental, and you declare a versioned build-depends on something that is also in experimental, then you *must* make sure that you also declare a versioned build-depends on any other packages from experimental that your direct build-dependencies depend on; otherwise, your package *will not build*. It is, of course, not necessary to also declare versioned build-depends on indirectly-required packages from unstable. Is there a tool to recurively list version of dependencies, as reportbug does? Justin (Please Cc me) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
