Bug#459712: build-conflicts with its own runtime
Faidon, On Thu, Apr 03, 2008 at 10:10:32PM +0300, Faidon Liambotis wrote: > Kilian Krause wrote: > >>In the case that it is, how would you feel about making the sample > >>build/run conditional on the presence of libpt in the build system? > > > >Well, it was very much needed as a precaution in the past - especially on > >the non-trivial architectures. Doing a conditional test without enforcing > >it > >to FTBFS the package would just reintroduce that harm with a very low bar > >to > >jump over. If you think it is seriously needed we should add the > >DEB_BUILD_OPTIONS switch and conditionalize it in there - or plain not run > >it at all. > I wasn't specific enough about the conditional: > What I meant was, skipping the tests altogether if > /usr/lib/libpt.so.1.10.1 is found. > > That way, it'll do the runtime test on clean chroots but skip it in > development environments, which is much better than having a > DEB_BUILD_OPTIONS. > > Any objections to that? the check should verify neither libpt.so nor libpt.so.$(SOVER) are available. If you can then verify that this does no longer cause a misleading false positive (with the check failing before) then should be able to safely commit. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#459712: build-conflicts with its own runtime
Kilian Krause wrote: In the case that it is, how would you feel about making the sample build/run conditional on the presence of libpt in the build system? Well, it was very much needed as a precaution in the past - especially on the non-trivial architectures. Doing a conditional test without enforcing it to FTBFS the package would just reintroduce that harm with a very low bar to jump over. If you think it is seriously needed we should add the DEB_BUILD_OPTIONS switch and conditionalize it in there - or plain not run it at all. I wasn't specific enough about the conditional: What I meant was, skipping the tests altogether if /usr/lib/libpt.so.1.10.1 is found. That way, it'll do the runtime test on clean chroots but skip it in development environments, which is much better than having a DEB_BUILD_OPTIONS. Any objections to that? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459712: build-conflicts with its own runtime
Faidon, On Thu, Apr 03, 2008 at 07:29:59PM +0300, Faidon Liambotis wrote: > [the following is a more useful description of the bug than the irc log] > > pwlib and pwlib-titan build-conflict with their runtime parts besides > the -dev parts. > I think this is being done because a sample program is built and run > when the package builds as a mean to catch runtime errors/screwups early. right. There were some pretty regular cases when subsequent builds were running fine but executing the lib was then failing with runtime errors. Therefore this runtime check at build time was neccessary to be introduced. > I'm not sure, however, if the conflict is really needed. Unfortunately it has been in the past. > The current situation is bad because people trying to do build tests on > their desktops have to uninstall ekiga among others. They can still install a fresh chroot (build flavour) which will then allow them to be clean with the build-requirements that might otherwise demand them to upgrade the entire system to quite recent versions - and screw up their daily desktop install. Apart from that it's way easier to control (security wise) and eventually even wrap up and copy/move around. For these and other reasons it has not been that much of a problem until now. I have before and would still even actively discourage any "bug reporter" of this kind of bugs to do this "native development" and rather go for chroot/vserver/xen etc.. The ekiga-snapshots have received a DEB_BUILD_OPTIONS switch to disable this due to some demand. It should not be a problem to copy this over back to Debian. > Kilian, you've added both the conflicts and the sample build/run. > Have you investigated if the conflicts is needed? Yes. > In the case that it is, how would you feel about making the sample > build/run conditional on the presence of libpt in the build system? Well, it was very much needed as a precaution in the past - especially on the non-trivial architectures. Doing a conditional test without enforcing it to FTBFS the package would just reintroduce that harm with a very low bar to jump over. If you think it is seriously needed we should add the DEB_BUILD_OPTIONS switch and conditionalize it in there - or plain not run it at all. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#459712: build-conflicts with its own runtime
[the following is a more useful description of the bug than the irc log] pwlib and pwlib-titan build-conflict with their runtime parts besides the -dev parts. I think this is being done because a sample program is built and run when the package builds as a mean to catch runtime errors/screwups early. I'm not sure, however, if the conflict is really needed. The current situation is bad because people trying to do build tests on their desktops have to uninstall ekiga among others. Kilian, you've added both the conflicts and the sample build/run. Have you investigated if the conflicts is needed? In the case that it is, how would you feel about making the sample build/run conditional on the presence of libpt in the build system? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459712: build-conflicts with its own runtime
Package: libpt-dev Severity: normal 10:04 * nyu grumbles at libpt-dev and its Build-Conflict with itself forcing him to uninstall ekiga 10:08 < moray> Build-Conflicting with yourself sounds like a wrong way to fix a bug 10:19 < paravoid> nyu: afaik there was no other way 10:19 < paravoid> I'm in pkg-voip but haven't really touched the package 10:19 < paravoid> upstream's makefiles are a big mess 10:21 < paravoid> thinking about it 10:21 < paravoid> there is no reason why you should be forced to uninstall ekiga 10:21 < paravoid> the source is build-conflicting with libpt-*dev* 10:22 < paravoid> oh no, it conflicts with the runtime too 10:22 < paravoid> ouch. 10:22 < paravoid> nyu: please fill a bug -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
