Re: Hardening patch
On Tue, 2011-09-13 at 08:51:17 +0200, Raphael Hertzog wrote: > On Tue, 13 Sep 2011, Guillem Jover wrote: > > I installed iceweasel on an ARM system (Thecus N2100), w/o X forwarding, > > and no user profile, so it just stops when it's not able to find the > > DISPLAY, but that should be good enough to get timings close to just the > > startup relocation times, which is what the ld.so stats show on amd64 > > for example. Caches flushed on each iteration, which were pretty > > consistent, I've included two different ones for each: > > I did the same on my eSATA SheevaPlug (armel too) and I don't get the same > results than you. [SheevaPlug tests] > > As it can bee seen the difference is pretty significant. > > As it can be seen, the difference is not something that affects > all armel machines in the same way. > > I did 10 run of each, dropped the biggest value and did the mean > value on the rest: > - bind lazy: 1.842s > - bind now: 1.910s > > Difference: +3,6 % Well an eSATA SheevaPlug is a pretty fast ARM machine! In any case it was not my intention to imply all ARM machines would be affected equally. I said the impact would be more noticable on slow architectures, which ARM tends to be. In this case I/O is most probably the culprit, something I hinted at on my first mail on this sub-thread. And this will affect any system with slow I/O. > > > Feel free to change it if you think it's better that way. I'm not attached > > > to it. > > > > I'm changing it now on my local tree, will be included in my next > > push. I took the commit out from my push because this was still under discussion, that does not mean I've changed my mind though and I still do not really feel comfortable uploading a dpkg defaulting to bind now. > Given my test, I'm not convinced it's the right course of action. > > I did the same test on my i386 setup and I got this: > - bind lazy: 0.320s > - bind now: 0.330s > > Difference: +3,1 % > > At the very least, we could keep it enabled for i386/amd64, no ? I've written some of this in some previous mail, but I'll repeat. This can have real impact on performance, it potentially affects the whole archive (once it all switches to using dpkg-buildflags), and even on overally fast archiectures it might still affect a range of its slow systems, once bind now is set on an object (via DF_1_NOW, DF_BIND_NOW or DT_BIND_NOW) it cannot be disabled by neither of dlopen(RTLD_LAZY) nor environment variables, it's trading an optimization with a security measure. So given its obvious drawbacks (something the other options do not seem to present), that we can always change it in the future, I don't think the current default should be changed. In this kind of case our stance should really be “if in doubt, do not change”. But if this was to get changed, this is something the project at large should get consensus on, not just the dpkg team. Of course specific maintainers are free to choose compilation options for their own packages, because that does (generally) have a global impact, and they can assess what side of the trade off is more important. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920023705.ga19...@gaara.hadrons.org
Re: Some upcoming dpkg changes, test and feedback welcome
On Wed, 2011-07-20 at 14:32:50 +0200, Raphael Hertzog wrote: > On Wed, 20 Jul 2011, Guillem Jover wrote: > > > I have also decided to not export the build flags in the environment by > > > default. If the caller really wants this, he should set > > > DPKG_EXPORT_BUILDFLAGS. > > > > Why? > > Because many people believe that the correct way to pass CFLAGS to the > build system is on the ./configure command line and not through the > environment. > > And debian/rules doesn't know all variables that buildflags.mk might > set so it can't reliably call unexport on all variables. Instead it should > use a flag that controls the behaviour of buildvars.mk. Ok, that makes sense. > That said if you believe the correct default is to export the variables > I'm happy to reverse the test and ask people who don't want it in the > environment to set DPKG_DONT_EXPORT_BUILDFLAGS. > > I really don't have any personal preference here. I find having to define DPKG_EXPORT_BUILDFLAGS a bit ugly (less than DPKG_DONT_EXPORT_BUILDFLAGS though). What about shifting completely the responsibility to the includer over what specific variables to export instead. As in: -include /usr/share/dpkg/buildflags.mk export CFLAGS CPPFLAGS CXXFLAGS LDFLAGS ? Some packages might need to do that in any case, so it seems like a nicer interface, with a bit less magic and more explicit. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920031445.gb19...@gaara.hadrons.org
Re: Some upcoming dpkg changes, test and feedback welcome
On Fri, 2011-07-29 at 16:31:36 +0200, Raphael Hertzog wrote: > On Wed, 20 Jul 2011, Raphael Hertzog wrote: > > Thus my personal preference would be to provide something to cover > > those use cases. > > I attached a patch for this. I ended up diverging slightly on the > variable names to be more consistent. Given that my remarks probably apply to most of the other make snippets and variables, you went ahead anyway, and I cannot be bothered to argue against this, I'll at least comment on the naming/implementation: > +# DEB_SOURCE_PACKAGE: the source package name Why DEB_SOURCE_PACKAGE instead of say, DEB_SOURCE? I guess it depends if we want to map to field names or to more descriptive (although probably redundant) variable names. > +# DEB_VERSION: the full version of the package > +# DEB_VERSION_NOREV: the package's version without the Debian revision > +# DEB_VERSION_NOEPOCH: the package's version without the Debian epoch > +# DEB_VERSION_UPSTREAM: the package's upstream version These do not seem to have ended up being completely consistent, there's a mix of variables listing what's missing, and variables listing what's included. What about something like: DEB_VERSION DEB_VERSION_EPOCH_UPSTREAM DEB_VERSION_UPSTREAM_REVISION DEB_VERSION_UPSTREAM instead? > +# DEB_DISTRIBUTION: the first distribution of the current entry in > debian/changelog Why only the first, what makes it special? If there's multiple filter can always be used. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920042753.ga21...@gaara.hadrons.org
