FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 09-08-2011, 01:23 PM
Raphael Hertzog
 
Default Proposal for a "Bits from dpkg developers"

On Wed, 07 Sep 2011, Guillem Jover wrote:
> It's been some time now since last upload (a busy summer for me with
> guests over during most of it!), and quite some changes have
> accumulated, so let's set as tentative target this next sunday for
> 1.16.1.

Given the number of disruptive changes, it's important to accompany
the upload with a d-d-a mail. I have thus prepared a draft here:
http://titanpad.com/wHeHZd9yrs

Some important points to note:
- I mention a backport that I plan to prepare once this version
reaches testing. If anyone thinks it's a bad idea, shout up
now and tell me why.
- I speak quickly of multiarch at the end to announce that 1.16.2
will have it, that it will go to experimental first and that
it will happen relatively quickly. Guillem, tell me if this
is ok with you.

For your convenience, here's a copy of the current version. If you
see spelling mistakes, please correct them in the titanpad copy.
Thank you.

----
Subject: Bits from dpkg developers - dpkg 1.16.1

Hello,

we just released dpkg 1.16.1 to unstable. It comes with a large
number of changes that you need to be aware of. Please read carefully.

Disruptive changes
------------------

* dpkg-buildpackage no longer exports CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS

It was not the proper approach to inject build flags since those
variables would not be set when calling debian/rules directly. So
we introduced dpkg-buildflags to solve the problem, and each
package is then responsible of retrieving the flags and injecting
them in the build process.

Any CDBS package should already use dpkg-buildflags transparently.
Packages using dh with debian/compat=9 are also covered. All the
other packages need to be adjusted. But it's now easier than before
with dpkg-dev 1.16.1.

With an autoconf-based package, you can adjust your ./configure
invocation in debian/rules like this:

./configure $(shell dpkg-buildflags --export=configure)

If you want to export the compilation flags in the environment like
dpkg-buildpackage used to do, you can simply put this at the top of
your debian/rules:

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk

You can also use “-include” to not fail when the file is missing and
make the package more backport-friendly. Otherwise, in both cases
you will have to build-depend on dpkg-dev (>= 1.16.1). We'll try to
provide a backport at least for squeeze to make it easier to
backport packages using those features.

* dpkg-buildflags now returns hardening build flags by default

While the Ubuntu archive already enables hardening by default, this
change might break some packages in Debian (either at build or at
run-time). If that is the case, you must be aware that you can
disable the problematic hardening feature by setting
DEB_BUILD_MAINT_OPTIONS in debian/rules. See dpkg-buildflags(1) for
details. Of course, you can only be affected if you're actually
using dpkg-buildflags as expected (see previous point).

PIE is the only hardening feature that is not enabled by default but
if your package supports it, it's a good idea to enable it.

Note that “$(shell dpkg-buildflags --export=configure)” does not
inherit environment variables set via "export" in the rules files,
so if you use that construct and want to enable PIE (or disable
something else), you must embed the variable initialization
like this:

dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS="hardening=+pie" dpkg-buildflags
[...]
./configure $(shell $(dpkg_buildflags) --export=configure)

* “dpkg-source -b” on a “3.0 (quilt)” source package will fail if it
detects upstream changes which are not managed by a quilt patch.

You are expected to call “dpkg-source --commit” if you want to
record those changes permanently. In this process, you will have
to give a patch name and you will be invited to edit the DEP-3
headers[1] of the new patch.

New features
------------

* When dpkg-source automatically applies patches at the start of the
build process, it will also automatically unapply them at the end
of a successful build. This should provide a better experience to
people building from a VCS repository with patches kept unapplied.

* There are some new trigger directives ("interest-noawait" and
"activate-noawait") that work like the existing directives except
that packages activating the triggers are not put in the
"triggers-awaited" status, they go straight to "installed" or
"triggers-pending". The difference is significant because packages
in "triggers-awaited" do not satisfy dependencies and can thus
force an early trigger processing that we'd like to avoid.

If the trigger processing is not critical for the activating package
to actually work, then you should consider using these new
directives. If you do so, you will have to add a
“Pre-Depends: dpkg (>= 1.16.1)” to ensure the new dpkg is
installed even before your package is unpacked. See deb-triggers(5)
for details.

* dpkg-dev now provides some (self-documented) Makefile snippets that
you can include in debian/rules in order to set some variables that
are frequently useful in a such a file:
* /usr/share/dpkg/default.mk
This file includes all the files listed below.
* /usr/share/dpkg/architecture.mk
This sets all the variables that you can retrieve with
dpkg-architecture.
* /usr/share/dpkg/buildflags.mk
This sets CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS with the values
returned by dpkg-buildflags. The variables are exported in the
environment only if DPKG_EXPORT_BUILDFLAGS is set.
* /usr/share/dpkg/pkg-info.mk
This provides information extracted from the changelog and the
control file like source package name and various version
related variables.
* /usr/share/dpkg/vendor.mk
This provides some vendor related information and a macro that
can be used to verify whether the current vendor derives from
a given distribution.

* dpkg-buildflags supports new environment variables
(DEB_<flag>_MAINT_<operation>) that are meant to be used by the
package maintainer to adjust the set of build flags returned. Two
new operations are now available (PREPEND and STRIP), they
complement SET and APPEND which were already supported.

This ensures that the maintainer can adjust the build flags even
if the dpkg-buildflags call is hidden behind an helper script.

* dpkg-deb gains --raw-extract which combines --extract and --control.
The resulting directory has the required structure to be fed to a
new invocation of “dpkg-deb --build”. Very useful for quick
hand-made changes to a package.

* start-stop-daemon gains --status to help implement LSB Init Script
status actions.

Misc changes
------------

* The Installed-Size field is now computed with “du --apparent-size”
so that the current filesystem block size should no longer affect
the resulting value. It will usually be smaller compared to the
previously generated value.

Multiarch
---------

This version does not yet have multiarch support (but it does know
the Multi-Arch field, so it will no longer output the unknown field
warning). The next version (1.16.2) will be the one introducing
multiarch support and shall be uploaded to experimental in the
hopefully not-too-distant future.

Thank you for your attention.

Guillem and Raphaël,
the dpkg maintainers.

[1] DEP-3: http://dep.debian.net/deps/dep3
-----

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110908132310.GG23590@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110908132310.GG23590@rivendell.home.ouaza.com
 
Old 09-23-2011, 05:03 AM
Guillem Jover
 
Default Proposal for a "Bits from dpkg developers"

On Thu, 2011-09-08 at 15:23:10 +0200, Raphael Hertzog wrote:
> Given the number of disruptive changes, it's important to accompany
> the upload with a d-d-a mail. I have thus prepared a draft here:
> http://titanpad.com/wHeHZd9yrs

Ok! Release tagged, pushed and uploaded.

I reworded some things, and added the new stuff since 1.15.7 that I
mentioned on my other mail. Hope to not have missed anything else
important/user visible. Please take a look, and feel free to send.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110923050329.GA18799@gaara.hadrons.org">http://lists.debian.org/20110923050329.GA18799@gaara.hadrons.org
 
Old 09-23-2011, 05:25 AM
Jonathan Nieder
 
Default Proposal for a "Bits from dpkg developers"

Guillem Jover wrote:

> Ok! Release tagged, pushed and uploaded.
>
> I reworded some things, and added the new stuff since 1.15.7 that I
> mentioned on my other mail. Hope to not have missed anything else
> important/user visible. Please take a look, and feel free to send.

Re the new triggers:

| If the trigger processing is not critical for the activating package
| to actually work, then you should consider using these new
| directives. If you do so, you will have to add a
| “Pre-Depends: dpkg (>= 1.16.1)” to ensure the new dpkg is
| installed even before your package is unpacked. See deb-triggers(5)
| for details.

Has it been discussed on debian-devel whether such a Pre-Depends
is worth it, and if so for which packages?

I personally think that it really would be worth it in this case for
any package of priority "standard" or lower (and maybe even packages
of priority "important"), but if we're making this announcement
without having had that discussion, then the email should say
something like "Before doing so, please consult debian-devel so the
impact on upgrades can be considered".

Thanks,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110923052548.GB2873@elie">http://lists.debian.org/20110923052548.GB2873@elie
 
Old 09-23-2011, 06:25 AM
Raphael Hertzog
 
Default Proposal for a "Bits from dpkg developers"

Hi,

On Fri, 23 Sep 2011, Guillem Jover wrote:
> I reworded some things, and added the new stuff since 1.15.7 that I
> mentioned on my other mail. Hope to not have missed anything else
> important/user visible. Please take a look, and feel free to send.

Thanks! It looks great, I made a few typo fixes, added a sentence wrt
Jonathan's concern and sent it.

On Fri, 23 Sep 2011, Jonathan Nieder wrote:
> | If the trigger processing is not critical for the activating package
> | to actually work, then you should consider using these new
> | directives. If you do so, you will have to add a
> | “Pre-Depends: dpkg (>= 1.16.1)” to ensure the new dpkg is
> | installed even before your package is unpacked. See deb-triggers(5)
> | for details.
>
> Has it been discussed on debian-devel whether such a Pre-Depends
> is worth it, and if so for which packages?

No, I expect each package maintainer to discuss it if they feel the need.
I put a sentence for this in the final version I just sent.

> I personally think that it really would be worth it in this case for
> any package of priority "standard" or lower (and maybe even packages
> of priority "important").

More than the priority of the package, it's the impact of the trigger
that must be considered. IMO it's totally worth it for a package like
man-db whose triggers is almost always activated.

bash-completion is not priority standard but was intending to have a
trigger on /bin /usr/bin and so on. This one should definitely need
to use the new form too!

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110923062547.GB11223@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110923062547.GB11223@rivendell.home.ouaza.com
 
Old 09-23-2011, 06:39 AM
Jonathan Nieder
 
Default Proposal for a "Bits from dpkg developers"

Raphael Hertzog wrote:

> It looks great, I made a few typo fixes, added a sentence wrt
> Jonathan's concern and sent it.

Thanks! (Just for the record, it was not really the maintainers that
are unsure that I was worried about. ;-) And such a Pre-Depends is
basically always safe, as long as the dpkg maintainers know about it
and can avoid a Depends/Pre-Depends or Breaks/Pre-Depends cycle.)

I hadn't realized it had been so long since the last release. This
upload looks like a good one.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110923063906.GA29036@elie">http://lists.debian.org/20110923063906.GA29036@elie
 

Thread Tools




All times are GMT. The time now is 12:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org