FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-29-2011, 03:25 PM
"Wesley W. Terpstra"
 
Default new buildd dependency resolution breaks self depends?

I've read that there was a recent change made to the buildd resolution with regards to ensuring that consistent package versions are used on the builds [0]. Is it possible that this changed also messed up self-dependency resolution?


My package, mlton, has a versioned dependency on itself for version >= 20070826. As it is a compiler for SML written in SML, it needs a previous version of itself installed in order to compile the new version. Previously, this has presented no problems; the buildd installed the old version and compiled the new version. Now, the buildd demands that the same version be installed as is to be built [1]:


mlton/alpha dependency installability problem:


mlton (= 20100608-3) build-depends on one of:
- mlton (= 20100608-3)
... this is, of course, impossible. The buildd must install the old version in order to build the new. I have a suspicion that an overzealous 'use the same version' rule in the dependency resolver might be the cause of this bug.


Thanks for any help understanding why the buildd system will no longer attempt to build my package!

[0] http://lists.debian.org/debian-policy/2011/03/msg00103.html

[1] https://buildd.debian.org/status/package.php?p=mlton
 
Old 03-29-2011, 03:52 PM
Julien Cristau
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 17:25:14 +0200, Wesley W. Terpstra wrote:

> I've read that there was a recent change made to the buildd resolution with
> regards to ensuring that consistent package versions are used on the builds
> [0]. Is it possible that this changed also messed up self-dependency
> resolution?
>
> My package, mlton, has a versioned dependency on itself for version >=
> 20070826. As it is a compiler for SML written in SML, it needs a previous
> version of itself installed in order to compile the new version. Previously,
> this has presented no problems; the buildd installed the old version and
> compiled the new version. Now, the buildd demands that the same version be
> installed as is to be built [1]:
>
> *mlton/alpha dependency installability problem:*
>
> mlton (= 20100608-3) build-depends on one of:
> - mlton (= 20100608-3)
>
> ... this is, of course, impossible. The buildd must install the old version
> in order to build the new. I have a suspicion that an overzealous 'use the
> same version' rule in the dependency resolver might be the cause of this
> bug.
>
As far as I can tell the problem is that you switched the mlton binary
package to 'Architecture: all'. Which means it's available on all
architectures already in the new version, even though it's not
installable.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110329155223.GG3159@radis.liafa.jussieu.fr">http ://lists.debian.org/20110329155223.GG3159@radis.liafa.jussieu.fr
 
Old 03-29-2011, 04:08 PM
Joachim Breitner
 
Default new buildd dependency resolution breaks self depends?

Hi,

Am Dienstag, den 29.03.2011, 17:52 +0200 schrieb Julien Cristau:
> > *mlton/alpha dependency installability problem:*
> >
> > mlton (= 20100608-3) build-depends on one of:
> > - mlton (= 20100608-3)
> >
> > ... this is, of course, impossible. The buildd must install the old version
> > in order to build the new. I have a suspicion that an overzealous 'use the
> > same version' rule in the dependency resolver might be the cause of this
> > bug.
> >
> As far as I can tell the problem is that you switched the mlton binary
> package to 'Architecture: all'. Which means it's available on all
> architectures already in the new version, even though it's not
> installable.

sounds similar to what just happend to me with ghc:
http://lists.debian.org/debian-haskell/2011/03/msg00108.html

In this case, with some help of the ftp team this could be resolved. But
in your case, as it is not transitional, it looks harder. I guess you
need to ensure that version n+1 can be built using the arch:any packages
of version n and the arch:all packages of either version n or version n
+1... or undo the package split.

Greetings,
Joachim


--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
 
Old 03-29-2011, 04:10 PM
"Wesley W. Terpstra"
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 5:52 PM, Julien Cristau <jcristau@debian.org> wrote:

As far as I can tell the problem is that you switched the mlton binary
package to 'Architecture: all'. *Which means it's available on all

architectures already in the new version, even though it's not

installable.

Ahh! That makes a lot of sense, thanks.
I'll need to figure out a way to work-around this.
 
Old 03-29-2011, 04:42 PM
Kurt Roeckx
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 05:52:23PM +0200, Julien Cristau wrote:
> As far as I can tell the problem is that you switched the mlton binary
> package to 'Architecture: all'. Which means it's available on all
> architectures already in the new version, even though it's not
> installable.

If I understand the situation, this means the buildd's already see
the new mlton arch all in the Packages file for the buildds. But
you won't see in on the mirrors until the arch any package for
that arch is available. And the arch all binary package has a
strict version requirement binary any package.

As long as the Packages file for the buildds mentions this arch
all package, no buildd can build it, because it only considers
installing the latest version. But it should get removed
from that file after 24 or 32 hours or something. In which case
we'll only see the old version, can install those, and things should
work from there.

So I think you either need to be patient, or have a less strict
version requirement.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110329164239.GA13477@roeckx.be">http://lists.debian.org/20110329164239.GA13477@roeckx.be
 
Old 03-29-2011, 04:58 PM
"Wesley W. Terpstra"
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx <kurt@roeckx.be> wrote:

As long as the Packages file for the buildds mentions this arch
all package, no buildd can build it, because it only considers

installing the latest version. *But it should get removed

from that file after 24 or 32 hours or something. *In which case

we'll only see the old version, can install those, and things should

work from there.

I hope what you're telling me is true, because it will save *me a lot of work!
What I don't understand about your explanation: once the new all+i386 .debs hit unstable, won't the buildds see the new 'all' package in unstable and thus want to install it in preference to the old 'any' package even after it is removed from the Packages file? The 'all' package will still be uninstallable since it depends on the missing 'any' packages.

While I can fix the problem at hand by removing the mlton 'all' package for an upload, *I see a more troublesome problem on the horizon:
The basis, runtime, and compiler packages should all be at the same version to compile correctly. The basis package is an 'all' package which includes the cross-platform bits of the runtime*library.*The runtime and compiler are 'any' packages with compiled object code.

If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current problem), any future uploads will see that it has these versions available:mlton-compiler (= old-version) depends on runtime
mlton-runtime (= old-version) depends on basismlton-basis (= new version)... which I believe means that the old-version mlton-compiler package will be uninstallable since the old-version of the basis in unstable is hidden by the new-version.

Have I understood this problem correctly?
 
Old 03-29-2011, 05:27 PM
Kurt Roeckx
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 06:58:36PM +0200, Wesley W. Terpstra wrote:
> On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx <kurt@roeckx.be> wrote:
>
> > As long as the Packages file for the buildds mentions this arch
> > all package, no buildd can build it, because it only considers
> > installing the latest version. But it should get removed
> > from that file after 24 or 32 hours or something. In which case
> > we'll only see the old version, can install those, and things should
> > work from there.
> >
>
>
> What I don't understand about your explanation: once the new all+i386 .debs
> hit unstable, won't the buildds see the new 'all' package in unstable and
> thus want to install it in preference to the old 'any' package even after it
> is removed from the Packages file? The 'all' package will still be
> uninstallable since it depends on the missing 'any' packages.

Let's take a look at all current Packages files:
- The buildd Packages file, as seen by *all* the buildds, not only
the i386 one:
kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/buildd-sid/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture
Package: mlton-basis
version: 20100608-3
Architecture: all

Package: mlton-compiler
version: 20100608-3
Architecture: i386

Package: mlton
version: 20100608-3
Architecture: all

Package: mlton-tools
version: 20100608-3
Architecture: i386

Package: mlton-runtime-native
version: 20100608-3
Architecture: i386

Package: mlton-runtime-i486-linux-gnu
version: 20100608-3
Architecture: i386

Package: mlton-doc
version: 20100608-3
Architecture: all

The i386 unstable one:
kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/archive/sid/main/binary-i386/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture
Package: mlton-basis
version: 20100608-3
Architecture: all

Package: mlton-compiler
version: 20100608-3
Architecture: i386

Package: mlton-doc
version: 20100608-3
Architecture: all

Package: mlton-runtime-i486-linux-gnu
version: 20100608-3
Architecture: i386
[...]

The amd64 one:
kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/archive/sid/main/binary-amd64/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture
Package: mlton
version: 20100608-2
Architecture: amd64

Note that in unstable you don't see the arch arch all version
until the arch any version is also available. Or you would see
the old arch all version until the new arch any version is
available.

This means that the version from unstable should always be
installable, unless there is some other reason it's not like
a transition of some other library.

The problem is that the buildds currently also see the newer
arch all version. But this version will go away after some
time and it will only see the version from unstable.

> The basis, runtime, and compiler packages should all be at the same version
> to compile correctly. The basis package is an 'all' package which includes
> the cross-platform bits of the runtime library. The runtime and compiler are
> 'any' packages with compiled object code.
>
> If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current
> problem), any future uploads will see that it has these versions available:
> mlton-compiler (= old-version) depends on runtime
> mlton-runtime (= old-version) depends on basis
> mlton-basis (= new version)
> ... which I believe means that the old-version mlton-compiler package will
> be uninstallable since the old-version of the basis in unstable is hidden by
> the new-version.

The new version of mlton-basis will only be visible to the buildds
for about a day, after which they should have no problem building
it.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110329172733.GA14065@roeckx.be">http://lists.debian.org/20110329172733.GA14065@roeckx.be
 
Old 03-29-2011, 05:54 PM
"Wesley W. Terpstra"
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 7:27 PM, Kurt Roeckx <kurt@roeckx.be> wrote:

Note that in unstable you don't see the arch arch all version
until the arch any version is also available. *Or you would see

the old arch all version until the new arch any version is

available.

That's great! My thanks to whomever had the foresight to prevent this temporary dependency breakage for all->any dependencies. I guess this would otherwise have annoyed unstable users for packages that had yet to be built for their architecture..?


This means that the version from unstable should always be

installable, unless there is some other reason it's not like

a transition of some other library.

Yes, the libgmp3-dev -> libgmp-dev transition already bit me this way. I assumed I was in for more of the same with the self dependency.

The problem is that the buildds currently also see the newer

arch all version. *But this version will go away after some

time and it will only see the version from unstable.

If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable?

The new version of mlton-basis will only be visible to the buildds

for about a day, after which they should have no problem building

it.

Thank god.
 
Old 03-29-2011, 05:59 PM
"Wesley W. Terpstra"
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 7:10 PM, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:

Does mlton-basis depend on mlton-runtime or mlton-compiler to build?*
If the answer is yes, then most likely these should not be three seperate*source packages.

It's all one source package. I split it up the binaries because:1) about 60% of the package could be in an 'all' package.2) the runtime components for different architectures can be installed side-by-side... thus enabling cross-compilation.

If no, then why doesn't it just work or is the problem a previous version

causing a mess?

According to Kurt, there is no problem. It's all in my head.
 
Old 03-29-2011, 06:03 PM
Kurt Roeckx
 
Default new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
> The problem is that the buildds currently also see the newer
> > arch all version. But this version will go away after some
> > time and it will only see the version from unstable.
> >
>
> If I may ask, for what purpose do the buildds have a special list of
> packages above and beyond those in unstable?

So that in case various packages have to be build in an order,
where the seconds depends on the first being available and so on,
that it doesn't take weeks to get them all build. We would have
to wait at least a dinstall before the next one could be build,
assuming sometimes has the time to sign the package between
dinstalls.

It basicly just avoids a whole lot of delays.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110329180343.GA14772@roeckx.be">http://lists.debian.org/20110329180343.GA14772@roeckx.be
 

Thread Tools




All times are GMT. The time now is 09:37 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org