Re: Some upcoming dpkg changes, test and feedback welcome

[Raphael Hertzog]

On Tue, 20 Sep 2011, Guillem Jover wrote:
> > +# 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.

Yeah, for me the important keyword seemed to be "PACKAGE" but it was
confusing between source and binary so I ended up being specific with
SOURCE_PACKAGE but indeed DEB_SOURCE is ok given it maps to a field name.

Changed.

> > +# 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?

Fine with me, changed.

> > +# 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.

So that a simple equality test does a good approximation of what was
wanted in the few cases where there are multiple distributions. Because
simple equality test is what people are going to do since 99% of real life
usage in Debian implies a single distribution listed.

Otherwise everybody must always use filter and compare to the empty
string.

In the rare case where someone really wants the multiple distributions,
he can uses dpkg-parsechangelog directly.

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110921070239.gn4...@rivendell.home.ouaza.com

Re: Hardening patch

[Raphael Hertzog]

On Tue, 20 Sep 2011, Guillem Jover wrote:
> 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.
[...]
> 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.

Ok, you have convinced me. Please put your commit back and change the
default to disabled.

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110921070812.go4...@rivendell.home.ouaza.com

Re: Some upcoming dpkg changes, test and feedback welcome

[Guillem Jover]

On Wed, 2011-09-21 at 09:02:39 +0200, Raphael Hertzog wrote:
> On Tue, 20 Sep 2011, Guillem Jover wrote:
> > > +# 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.
> 
> So that a simple equality test does a good approximation of what was
> wanted in the few cases where there are multiple distributions. Because
> simple equality test is what people are going to do since 99% of real life
> usage in Debian implies a single distribution listed.
> 
> Otherwise everybody must always use filter and compare to the empty
> string.
> 
> In the rare case where someone really wants the multiple distributions,
> he can uses dpkg-parsechangelog directly.

Oh, but in Debian this should not happen as multiple distributions are
not supposed to be allowed [0]. And given that the package checks are
already Debian specific, say a safety net against uploading experimental
packages to unstable, it should be safe to assume there's only going
to be one distribution returned or the upload will fail anyway on DAK.
If the upload would succeed then the safety net would not actually be
safe as the order of the suites is not guaranteed.

So returning all the values is fine, and would be useful for other
derivatives where more than one is actually allowed, and for Debian
using equality should also be just fine (although using filter would
be more correct, would avoid archive checks assumptions and as such
catch possibly bogus uploads earlier).

regards,
guillem

[0] 



-- 
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/20110921175517.ga18...@gaara.hadrons.org

Re: dpkg build under Mac OS X failed

[Guillem Jover]

Hi!

On Tue, 2011-09-20 at 22:12:36 -0700, stu...@zulazon.com wrote:
> I tried to build dpkg from source under Mac OS X 10.6.8, and succeeded
> only by
> 
> altering  dpkg-linker.m4 to remove the -O1 flag the Apple linker ld didn't
> understand getting newer versions of autotools using the -i flag for
> autoreconf

For the ld issue, you can use --disable-linker-optimisations, but this
has already bitten some people, and using those flags by default is
clearly not portable, so I'll be disabling them on the next release
(1.16.2).

> It would have been very helpful if there had been a README or INSTALL with
> instructions, particularly the prerequisites and procedures for building
> dpkg.

I had at some point a slightly improved README with more documentation,
but seem to have lost it. I'm attaching a new more complete one which I
hope would have covered your needs? The only slight drawback is that it
duplicates some of the information already contained in the Debian
source package metadata, which could become out of date, but it should
be of help for people building from git.

The INSTALL file is present but only after having prepared the release
for distribution, which is not the case when getting the source from
git.

> So, in m4/dpkg-linker.m4 I removed the -O1 flag from the default LDFLAGS,
> re-ran autoreconf etc., and everything build and installed Ok.  dpkg
> --help worked, but at this point I had no further need for dpkg, since I'd
> already dealt manually with the dependencies for building a number of
> packages from source.

Well that's always going to be true when bootstrapping a package
manager. Also I'm not sure it makes much sense to use dpkg on a
foreign system, when most (if not all) of the software installed is
not managed by dpkg, which kind of renders it purposeless.

If you are still interested in just having dpkg around in your
Mac OS X, then using the MacPorts dpkg port might be easier?

> make check doesn't get past CCLD t-test, which has an undefined symbol
> _libintl_gettext.  There had been no gettext on the system, but I
> build that, and the necessary symbol seems to be defined (according to
> nm) in the libintl.a and libintl.dylib in a directory I tried to tell
> the linker about via LDFLAGS, but apparently I haven't discovered the
> right way to let the dpkg build system know about it.  My time for
> this has run out now.

gettext should be required when preparing the tar distribution source
tree, and I'm surprised autoreconf didn't complain about missing
AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION macros?

In any case if you get that error even when disabling NLS support, or
when building dpkg from a tarball release but w/o gettext installed
I'd be interested in the build logs, because that'd be a problem in
dpkg's build system.

thanks,
guillem
dpkg - Debian's package maintenance system

The primary interface for the dpkg suite is the ‘dselect’ program;
a more low-level and less user-friendly interface is available in
the form of the ‘dpkg’ command.


Releases


The current legacy, stable and development releases can be found at:

  

For older releases check:

  


Mailing List


The subscription interface and web archives can be found at:

  

The mailing list address is:

  debian-dpkg@lists.debian.org


Source Repository
-

  
  


Building from git source


To prepare the source tree before starting the build process, some software
needs to be installed, additional software might provide optional features.

The minimum software required to build dpkg is:

  C89 compiler with few C99 extensions (see doc/coding-style.txt)
  GNU make
  GNU autoconf >= 2.60
  GNU automake >= 1.8
  GNU gettext  >= 0.18
  pkg-config
  flex
  perl

To run the test suite («make check»):

  TimeDate perl module
  IO-String perl module

To enable optional functionality or programs, this software might be needed:

  zlib (used instead of the command-line tool)
  liblzma (from the xz project; used instead of the command-line tool)
  libbzip2 (from the bzip2 project; used instead of the command-line tool)
  libselinux (needed for SELinux support)
  curses compatible library (needed for dselect)

To enable translated or additional («make doc») documentation this
software will be needed:

  po4a >= 0.36.4
  pod2man
  doxygen
  dot

To enable code coverage («./configure --enable-coverage; make coverage»)
this software is needed:

  lcov (from the Linux Test Project)
  Devel-Cover perl module


After installing the needed software, and running the following command on
the git tree:

  $ autoreconf -f -i

the source should be equivalent to the distributed tar source.


Building from tar source


The instructions to build the distributed source are in

Re: Some upcoming dpkg changes, test and feedback welcome

[Raphael Hertzog]

On Wed, 21 Sep 2011, Guillem Jover wrote:
> So returning all the values is fine, and would be useful for other
> derivatives where more than one is actually allowed, and for Debian
> using equality should also be just fine (although using filter would
> be more correct, would avoid archive checks assumptions and as such
> catch possibly bogus uploads earlier).

I knew that Debian does not allow multiple distro, and it's precisely
for this that I expect any usage will end up using equality test which
in turn will lead to problems for distributions using multiple distro
if we return multiple distros.

But this is all wishful thinking at this point given that I have no use
case where some analysis of the distributions returned needs to be
portable across several derivatives and Debian itself.

So I updated the field to return all distributions because either way
it's not going to change much (and it's always possible to add
DEB_FIRST_DISTRIBUTION later if we ever have to reconsider the question).

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110921205232.ga25...@rivendell.home.ouaza.com

Re: Next upload 2011-09-11 (dpkg 1.16.1)

[Guillem Jover]

Hi!

On Wed, 2011-09-14 at 08:00:08 +0200, Guillem Jover wrote:
> On Wed, 2011-09-07 at 06:18:06 +0200, Guillem Jover wrote:
> > I still have some changed to push, which I'll be doing during today,
> > and a second push tomorrow or so, to give time for some more testing
> > before the upload. I'll be going through remaining issues with the
> > upload during the week too.
> 
> I didn't do the second push (with part of the remaining buffer API
> changes, needed for at least the --compare-versions fix) because it
> included some translatable string modifications, which were going to
> change with subsequent changes, to not create useless work for
> translators.

I ended up splitting and pulling out part of those dpkg_error buffer
API changes because I noticed I needed to change the subproc module
too, which started to cascade into too many places.

> Hope to push later today/tomorrow, and will probably be leaving some of
> the intrusive stuff for 1.16.2, after that leave some days for the
> pending issues and any possible new regressions.

Erm, ok so it took a bit more time than that because I wanted to be
extra careful, needed to fix the build system, etc. In any case now
that everything seems to have settled down and no additional
regressions have been spotted, I think tomorrow looks like a good day
to prepare the upload after having gone through the announcement
Raphaël has drafted, which might need some updates at least for the
late interfaces changes, and I think while we are at it, it'd made
sense to also include the changes since our last d-d-a announcment,
so since dpkg 1.15.7.

thanks,
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/20110922021001.ga15...@gaara.hadrons.org