Would prefer that all dpks would load when extracted, or be sent to a save file, like gzip. But I am only a beginner in coding.
Daniel T. Hasbrouck On Jan 17, 2017 8:38 PM, "Guillem Jover" <guil...@debian.org> wrote: > > Hi! > > I'd like to get some feedback from porters and package maintainers, > given that this affects at least both groups. Some background first. > > One of the reasons PIE has in the past not been enabled by default in > dpkg-buildflags, is because it introduced some slowness on some arches, > although this has somewhat changed recently. But also because > unconditionally setting it, breaks at least PIC builds. So PIE got > enabled recently by default in gcc, as it could easily control when it > is relevant. Although this has been done only for release architectures. > > At about the same time this was being considered, I realized that dpkg > could enable this "safely" by using gcc specs files. But this is in > any case also required to be able to disable PIE when it is implicitly > enabled by default in gcc. So we'll need specs files no matter what, > at least for now. > > While adapting dpkg-buildflags to cover for the new gcc defaults, I > unintentionally enabled PIE by default on all architectures, and when > I noticed, it seemed to make sense to leave it like that, because: > > * All previous build flags from dpkg-buildflags have always been > enabled globally and only blacklisted completely when they have > been non-functional. > * It's a more consistent interface for packages, as they get built > with the same flags everywhere. Otherwise we'd get PIE enabled by > default in release arches, disabled by default elsewhere, and > enabled or disabled depending on the package requesting so. > * It will mean that PIE coverage reporting will be shadowed in > lintian, because the tags only cover i386 and amd64, so maintainers > will probably stop enabling them globally. > > Matthias Klose recently filed an unclear report (#848129) on dpkg-dev > requesting to not enable PIE globally from dpkg-buildflags, and pretty > much immediately added a patch into gcc [P] to ignore dpkg-buildflags > PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did > not enable PIE explicitly (I only fully understood the request after > seeing the gcc patch). > > [P] < https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-6/debian/patches/ignore-pie-specs-when-not-enabled.diff?revision=9202&view=markup > > > Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS > does not even need to be exported from debian/rules, nor from the > dpkg architecture.mk fragment, or when dpkg-buildflags is used with its > --export=configure or --export=cmdline. It's also a layer violation. > It also breaks unrelated stuff as now gcc emits notes when it thinks > the -specs option should not be passed. And while I could certainly > have started an arms-race by adding counter-measures by randomizing > the filenames or something similarly ugly, that'd be pretty much silly > and childish. > > For better or worse, this does not affect the release architectures, > so by extension it should not affect the release, but it still sucks. > > So, I'd like to know how people feel about the requested interface > (i.e. not enabling PIE globally from dpkg-buildflags). If there's > consensus that porters and maintainers want that, I'll just change > dpkg-buildflags to do this, even though I think it's a very > suboptiomal behavior. > > Alternatively, porters could as well request PIE be enabled by default > in gcc on their port, which could make this also globally enabled. > > Thanks, > Guillem >
