Re: [Fink-devel] buildconflicts, buildlock
David R. Morrison wrote: [] The problem arises in the middle of a big compile of lots of packages. Not only. I had two messages from fink-users as evidence, but I tried it myself now. Turns out "fink build" and "fink install" behave differently, the first works as intended, the second doesn't: hilbert:costabel% fink install gnome-vfs2-shlibs Information about 4739 packages read in 4 seconds. The following package will be installed or updated: gnome-vfs2-shlibs dpkg-deb -b /sw/src/root-fink-buildlock-gnome-vfs2-2.6.1.1-15 /sw/src dpkg-deb: building package `fink-buildlock-gnome-vfs2-2.6.1.1-15' in `/sw/src/fink-buildlock-gnome-vfs2-2.6.1.1-15_2005.02.27-22.16.29_darwin-powerpc.deb'. Setting build lock... dpkg -i /sw/src/fink-buildlock-gnome-vfs2-2.6.1.1-15_2005.02.27-22.16.29_darwin-powerpc.deb dpkg: regarding .../fink-buildlock-gnome-vfs2-2.6.1.1-15_2005.02.27-22.16.29_darwin-powerpc.deb containing fink-buildlock-gnome-vfs2-2.6.1.1-15: fink-buildlock-gnome-vfs2-2.6.1.1-15 conflicts with openssl097-dev openssl097-dev (version 0.9.7d-1) is installed. dpkg: error processing /sw/src/fink-buildlock-gnome-vfs2-2.6.1.1-15_2005.02.27-22.16.29_darwin-powerpc.deb (--install): conflicting packages - not installing fink-buildlock-gnome-vfs2-2.6.1.1-15 Errors were encountered while processing: /sw/src/fink-buildlock-gnome-vfs2-2.6.1.1-15_2005.02.27-22.16.29_darwin-powerpc.deb ### execution of dpkg failed, exit code 1 Can't set build lock for gnome-vfs2 (2.6.1.1-15) If any of the above dpkg error messages mention problems with dependencies, fink has probably gotten confused by trying to build many packages at once. Try building just this current package. When that has completed successfully, you could retry whatever you did that led to the present error. Regardless of the cause of the lock failure, don't worry: you have not wasted compiling time! Packages that had been completely built before this error occurred will not have to be recompiled. Failed: buildlock failure hilbert:costabel% fink build gnome-vfs2-shlibs Information about 4739 packages read in 4 seconds. The following package will be built: gnome-vfs2-shlibs The following package will be removed: openssl097-dev Do you want to continue? [Y/n] Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
>From [EMAIL PROTECTED] Sat Feb 26 18:41:17 2005 From: Daniel Macks <[EMAIL PROTECTED]> To: fink-devel@lists.sourceforge.net Subject: Re: [Fink-devel] buildconflicts, buildlock References: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.4.1i Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: fink-devel@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/fink-devel>, <mailto:[EMAIL PROTECTED]> List-Id: Discussion for Fink developers and package maintainers List-Post: <mailto:fink-devel@lists.sourceforge.net> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/fink-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=fink-devel> X-Original-Date: Sat, 26 Feb 2005 18:38:56 -0500 Date: Sat, 26 Feb 2005 18:38:56 -0500 X-Virus-Scanned: by AMaViS 0.3.13pre2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on augustus.math.duke.edu X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 On Sat, Feb 26, 2005 at 03:21:30PM -0500, David R. Morrison wrote: > Actually, Justin, buildconflicts *had* been working recently. But as Martin > points out, the buildlock system has now broken it. That seems strange. In Engine.pm, the calls to *_buildlock are tightly wrapped around the phase_* calls that build the package. All of this is well *inside* the lines documented to: # remove buildconfilcts before new builds reinstall after build and # Reinstall buildconficts after the build dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
Daniel Macks <[EMAIL PROTECTED]> wrote: > On Sat, Feb 26, 2005 at 03:21:30PM -0500, David R. Morrison wrote: > > Actually, Justin, buildconflicts *had* been working recently. But as Martin > > points out, the buildlock system has now broken it. > > That seems strange. In Engine.pm, the calls to *_buildlock are tightly > wrapped around the phase_* calls that build the package. All of this > is well *inside* the lines documented to: > # remove buildconfilcts before new builds reinstall after build > and > # Reinstall buildconficts after the build > > dan > OK, I've done some experimenting and I understand this better now. Buildconflicts still works in 0.24.0, and was not broken by buildlock. If you have a package with "Buildconflicts: foo-dev", and foo-dev is installed when you try to build it, fink will still ask you if you want to remove foo-dev at the beginning of the process (and will refuse to proceed if you say no). The problem arises in the middle of a big compile of lots of packages. If foo-dev gets installed in the middle of the process, then there is no longer an opportunity to remove foo-dev, and the buildlock (correctly) interrupts the process when the buildconflicts is encountered. Even though this is correct behavior, it can be difficult for users to understand what's happening. I think we need better error messages for this situation, and I'll work on writing some. -- Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
Dave Vasilevsky <[EMAIL PROTECTED]> wrote: > On Feb 26, 2005, at 6:08 PM, David R. Morrison wrote: > > OK, in my opinion, this behavior as reported by Robert indicates that > > the > > buildlock system is not yet working as it should. > > It's working fine, it's catching a bug in Fink right away rather than > later. :-) > > > Fink is "supposed" to be able to switch back and forth among db3 vs. > > db42, > > or ncurses5 vs. libncurses5. So shouldn't we be trying to restore the > > dependencies of the buildlock package, instead of just refusing to > > install > > it? > > Fink never did this properly. In one invocation, it can accomplish > precisely ONE switch between replaceable packages, and sometimes it > even does that wrong. At least now we're not letting it pass when it > could cause an error. > > > (For example, we could add each new deb to the scanpackages database > > just after it's built, and then ask apt-get (rather than dpkg) to > > install > > the buildlock... which would "put back" a .deb that just got removed, > > presumably.) > > That's one idea. I was under the impression that Justin's shlibs > changes in post-0.24 would be re-calculating dependencies before and > after each build, which is another way to solve this issue. Am I right > or wrong about that? > > Dave > That's not relevant, actually. The issue is: which -dev packages are present at buildtime. Those aren't recalculated. -- Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
Daniel Macks wrote: [] BuildConflicts: freetype | freetype-hinting into the info file. This never worked. As well it shouldn't (at least not as you want), by rigorous logic of the OR operator. Just like: Depends: foo | bar means something like "Depends:foo | Depends:bar", your usage means "BC:freetype | BC:freetype-hinting". If you want to BConflicts with *both*, you'd need an AND list. You are right. This was actually a typo in my message, in the info file I had correctly BuildConflicts: freetype, freetype-hinting It was this version that did not work. -- Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
On Sat, Feb 26, 2005 at 03:21:30PM -0500, David R. Morrison wrote: > Actually, Justin, buildconflicts *had* been working recently. But as Martin > points out, the buildlock system has now broken it. That seems strange. In Engine.pm, the calls to *_buildlock are tightly wrapped around the phase_* calls that build the package. All of this is well *inside* the lines documented to: # remove buildconfilcts before new builds reinstall after build and # Reinstall buildconficts after the build dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
On Sat, Feb 26, 2005 at 12:07:57PM +0100, Martin Costabel wrote: > I have 2 loosely related questions: > > 1. What is the status of the BuildConflicts mechanism? I seem to > remember that some months ago this worked as intended, i.e. the > buildonly packages in question were removed before building and > reinstalled afterwards. There were problems when many packages were > installed at once, but this is normal and acceptable. > > Recently, I tried to use this mechanism to get rid of some of those > freetype 1 vs 2 conflicts by putting > > BuildConflicts: freetype | freetype-hinting > > into the info file. This never worked. As well it shouldn't (at least not as you want), by rigorous logic of the OR operator. Just like: Depends: foo | bar means something like "Depends:foo | Depends:bar", your usage means "BC:freetype | BC:freetype-hinting". If you want to BConflicts with *both*, you'd need an AND list. The "Conflicts" field documentation notes: This fields also supports versioned dependencies like the Depends field, but not alternatives (wouldn't make sense). where the term "alternatives" is defined (in the "Depends" field docs) as the use of "|". > 2. Is there any documentation of the buildlock system, in particular an > explanation of how it works and what was the problem this is supposed to > solve? Not one of the problems I had, it seems to me. From reading the > sources, I found that there is a no_buildlocks option, and I would > prefer this to be the default. There are even traces of a > "Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" > and the documentation know nothing about. This is just one of many flags and options that are for internal use by the fink code only. Saves having to rewrite whole chunks of code. > 3. Another undocumented config parameter is ConfFileCompatVersion. This probably *should* be documented, since it has some meaning for end-users. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
On Feb 26, 2005, at 6:08 PM, David R. Morrison wrote: OK, in my opinion, this behavior as reported by Robert indicates that the buildlock system is not yet working as it should. It's working fine, it's catching a bug in Fink right away rather than later. :-) Fink is "supposed" to be able to switch back and forth among db3 vs. db42, or ncurses5 vs. libncurses5. So shouldn't we be trying to restore the dependencies of the buildlock package, instead of just refusing to install it? Fink never did this properly. In one invocation, it can accomplish precisely ONE switch between replaceable packages, and sometimes it even does that wrong. At least now we're not letting it pass when it could cause an error. (For example, we could add each new deb to the scanpackages database just after it's built, and then ask apt-get (rather than dpkg) to install the buildlock... which would "put back" a .deb that just got removed, presumably.) That's one idea. I was under the impression that Justin's shlibs changes in post-0.24 would be re-calculating dependencies before and after each build, which is another way to solve this issue. Am I right or wrong about that? Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] buildconflicts, buildlock
Robert T Wyatt <[EMAIL PROTECTED]> wrote: > two cents from a beginner: > > At 3:55 PM -0500 2/26/05, Dave Vasilevsky wrote: > >Buildlocks solves several problems. > > > >Fink's dep engine isn't always smart. [snip] 'fink install > >bundle-gnome' [is] very likely to run into this problem. > > Good example! I've been installing a bunch of gnome thingies the last > several hours and getting plenty of these: > > dpkg: error processing fink-buildlock-gnome-apt-0.3.15-5 (--install): > dependency problems - leaving unconfigured > Errors were encountered while processing: > fink-buildlock-gnome-apt-0.3.15-5 > ### execution of dpkg failed, exit code 1 > Can't set build lock for gnome-apt (0.3.15-5) > [snip] > Most of these are packages wanting db3, at least one wants ncurses5, OK, in my opinion, this behavior as reported by Robert indicates that the buildlock system is not yet working as it should. Fink is "supposed" to be able to switch back and forth among db3 vs. db42, or ncurses5 vs. libncurses5. So shouldn't we be trying to restore the dependencies of the buildlock package, instead of just refusing to install it? (For example, we could add each new deb to the scanpackages database just after it's built, and then ask apt-get (rather than dpkg) to install the buildlock... which would "put back" a .deb that just got removed, presumably.) -- Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
no problem, I couldn't remember how it broke though I thought it was when Max removed my Engine changes. Either way those changes I made where wrong and I see the other side. I'll fix buildconflicts regardless. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 26-Feb-05, at 1:21 PM, David R. Morrison wrote: Actually, Justin, buildconflicts *had* been working recently. But as Martin points out, the buildlock system has now broken it. -- Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
two cents from a beginner: At 3:55 PM -0500 2/26/05, Dave Vasilevsky wrote: Buildlocks solves several problems. Fink's dep engine isn't always smart. [snip] 'fink install bundle-gnome' [is] very likely to run into this problem. Good example! I've been installing a bunch of gnome thingies the last several hours and getting plenty of these: dpkg: error processing fink-buildlock-gnome-apt-0.3.15-5 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: fink-buildlock-gnome-apt-0.3.15-5 ### execution of dpkg failed, exit code 1 Can't set build lock for gnome-apt (0.3.15-5) If any of the above dpkg error messages mention problems with dependencies, fink has probably gotten confused by trying to build many packages at once. Try building just this current package. When that has completed successfully, you could retry whatever you did that led to the present error. Regardless of the cause of the lock failure, don't worry: you have not wasted compiling time! Packages that had been completely built before this error occurred will not have to be recompiled. dpkg -r fink-buildlock-gnome-apt-0.3.15-5 (Reading database ... 141051 files and directories currently installed.) Removing fink-buildlock-gnome-apt-0.3.15-5 ... Failed: buildlock failure (for more details see: http://uts.cc.utexas.edu/~bentones/development/at-home/20050226a.txt and search for "failed") Most of these are packages wanting db3, at least one wants ncurses5, and then there are a couple of others..., but it's pretty easy to see where the problems are coming from now and mostly I just have to fink install whatever the problem package is, which will pick up the missing dependency, and then go up two levels in my bash command history and re-execute. Now if we could just make the package manager do this for us, or never have any more mixed dependencies again, or Anyway, I think the buildlock helps me to help myself. --robert --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
On Feb 26, 2005, at 6:07 AM, Martin Costabel wrote: 2. Is there any documentation of the buildlock system, in particular an explanation of how it works and what was the problem this is supposed to solve? Not one of the problems I had, it seems to me. From reading the sources, I found that there is a no_buildlocks option, and I would prefer this to be the default. There are even traces of a "Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" and the documentation know nothing about. Martin, Buildlocks solves several problems. Fink's dep engine isn't always smart. Suppose foo depends on bar, and bar conflicts/replaces with iggy. If you had bar installed and did 'fink install foo iggy', Fink might build and install first iggy and then foo. Now foo is being built without bar installed, since it's replaced by iggy. If it tries to link to a dylib in both bar and iggy, it will now be linked to iggy but will say 'Depends: bar'. This is BAD. Building with the wrong packages installed could also happen if the user removes a package while building something that depends on it. Or if the user is running multiple builds at once, one build could remove something needed by the other. The dep engine also gets confused in some other situations. When these problems occur, usually it results in Fink failing to build a package that really has no bug, or in Fink building a package that's not quite right (like the badly linked library situation discussed above). This causes all kinds of relatively mysterious bugs, and a lot of failed builds that lead to bug reports. We developers don't see it so often because we usually have a lot of packages installed already, but big builds like 'fink install bundle-gnome' on a brand new fink are very likely to run into this problem. All buildlocks does is while building a package, it installs a "fake" package which depends on everything the current build needs to build. Now, if somebody (a user or fink) tries to remove a package while building something that needs it, they'll get an error. And if a package is about to be built but something it needs is missing, rather than silently try to build and then breaking, the buildlock will fail to install. Then Fink will give the user a message that they should try again (which usually solves the problem), rather than a random build failure that results in an irate message to the mailing list :-) I'd say that a fair fraction of the error messages that we get on the lists, and the complaints people have about Fink, come from the problems I mentioned above. So it's very important that these situations not happen. And it's not trivial to "just" fix all the little things in the dep engine that can go wrong. Even if the current problems do get fixed, buildlocks will make sure new ones don't come up. I think it's very important for the sanity of our packagers that buildlocks remain on by default. Essentially the only reason to turn them off is if there's a bug in buildlocks. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] buildconflicts, buildlock
Actually, Justin, buildconflicts *had* been working recently. But as Martin points out, the buildlock system has now broken it. -- Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] buildconflicts, buildlock
I will revive buildconflicts again, and I say again cause I wrote it the first time and I believe Max disabled it because of an other issue which also affected the shlibs stuff. After over a year we found away around it for the shlibs stuff and I'm currently working on a system for fink to add and remove users and groups via info file that will embed into the deb files making the passwd package no longer needed. Once that is done I'll tackle buildconflicts again and try not to break other things this time :D so likely a few months away. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 26-Feb-05, at 4:07 AM, Martin Costabel wrote: I have 2 loosely related questions: 1. What is the status of the BuildConflicts mechanism? I seem to remember that some months ago this worked as intended, i.e. the buildonly packages in question were removed before building and reinstalled afterwards. There were problems when many packages were installed at once, but this is normal and acceptable. Recently, I tried to use this mechanism to get rid of some of those freetype 1 vs 2 conflicts by putting BuildConflicts: freetype | freetype-hinting into the info file. This never worked. Depending on the order of the two packages and on which one was installed, it either did nothing at all or gave me a circular dependency error. Now, with the arrival of the buildlock mechanism, Buildconflicts seems to be half dead: It is transformed into an ordinary Conflicts for the buildlock package, but there is no automatic removal any more, only a crash. And no automatic eventual restoration either, of course. As a message on the users list indicates, the message produced by this crash is not useful for normal users. 2. Is there any documentation of the buildlock system, in particular an explanation of how it works and what was the problem this is supposed to solve? Not one of the problems I had, it seems to me. From reading the sources, I found that there is a no_buildlocks option, and I would prefer this to be the default. There are even traces of a "Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" and the documentation know nothing about. 3. Another undocumented config parameter is ConfFileCompatVersion. -- Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] buildconflicts, buildlock
I have 2 loosely related questions: 1. What is the status of the BuildConflicts mechanism? I seem to remember that some months ago this worked as intended, i.e. the buildonly packages in question were removed before building and reinstalled afterwards. There were problems when many packages were installed at once, but this is normal and acceptable. Recently, I tried to use this mechanism to get rid of some of those freetype 1 vs 2 conflicts by putting BuildConflicts: freetype | freetype-hinting into the info file. This never worked. Depending on the order of the two packages and on which one was installed, it either did nothing at all or gave me a circular dependency error. Now, with the arrival of the buildlock mechanism, Buildconflicts seems to be half dead: It is transformed into an ordinary Conflicts for the buildlock package, but there is no automatic removal any more, only a crash. And no automatic eventual restoration either, of course. As a message on the users list indicates, the message produced by this crash is not useful for normal users. 2. Is there any documentation of the buildlock system, in particular an explanation of how it works and what was the problem this is supposed to solve? Not one of the problems I had, it seems to me. From reading the sources, I found that there is a no_buildlocks option, and I would prefer this to be the default. There are even traces of a "Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" and the documentation know nothing about. 3. Another undocumented config parameter is ConfFileCompatVersion. -- Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
