Op ma 20-10-2003, om 11:13 schreef Sven Luther: > On Mon, Oct 20, 2003 at 10:57:04AM +0200, Wouter Verhelst wrote: > > > Ideally, it could be automated, by delaying the build > > > of these packages by one day, and it would be fine. > > > > That's an option, although imperfect since it assumes that all > > architectures will always build all packages within one day, which > > simply isn't true. [...] > Also, i think it could be automated in having the autobuilder explicitly > check for build-dependencies versions, and don't trigger a rebuild when > the build-dependencies have no chance to be fullfillable. That's the idea of dep-wait. [...] > > First, let's get one misunderstanding out of the way: an autobuilder > > will not, by itself, put packages in dep-wait; only a human will. So, if > > a package failed due to unmet build-dependencies, it's a human who will > > have to prepare the list of dependencies for which a package will have > > to wait. Obviously, some people made errors in the ocaml situation > > (because of ignorance). > > Ah, i thought (from the ia64 or hppa autobuilder situation) that failed > packages where put on hold automatically, and then retrigered manually. In a way, they are. They're put "on hold" (read: the build fails, and they're stuck in state "building") automatically until someone has a look at them. Once that's done, they're put in a different queue, where they'll wait until all their build-dependencies are available. On faster architectures (such as ia64, dunno about hppa), I can imagine that by the time an admin has a look, everything is usually available, and as such can understand that they don't use dep-wait as much... > > Adding more explicite build-dependencies certainly is a possibility as > > it makes things clearer for autobuilder maintainers; however, it is > > maybe not the best solution if it is technically possible to build > > lablgl against previous versions of ocaml: it will make backporting a > > little harder. > > Well, i don't think it is a problem. There is not much sense in > backporting a library only, OK, if you say so. [...] > > I'll send a mail to the m68k porters' list, describing the problem, and > > outlining what needs to be done. That won't mean there will be no > > problems anymore, but it certainly will help. > > Ok, please CC debian-ocaml-maint for the archive. [...] > > > But if i understand the issues involved correctly, the first step of the > > > dependency chain will build, but all the other packages will drop again > > > from the needs-build queue, right ? > > > > Yes, and that's what should happen: if they can't build, they have to > > wait until they can. Packages that have to wait don't belong in > > needs-build. > > > > However, what has gone wrong in the past is that the dependencies which > > were being waited on were incorrect. Instead of depending on ocaml, we > > should've depended on the new version of the library. Which simply > > didn't happen. > > Yes. Adding explicit (>> version) build dependency to the libraries will > help there. I will add this to the debian/ocaml policy. If you'll do that, there will not be need for m68k maintainers to be notified about this... I'll check the packages in dep-wait to make sure this release builds easily; if you make sure ocaml packages use that explicit build dependency in the future, the problem will be solved. > > > Anyway, this helps, since now someone from the autobuilder folk is aware > > > of the problem, and things will advance. > > > > Yes, I think I'm fully aware of what's happening and what needs to be > > done. > > Ok, thanks. > > Sorry for having insisted, np. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*.
Attachment:
signature.asc
Description: Dit berichtdeel is digitaal ondertekend