Bug#960926: developers-reference: updating the packages copyright notices

[Raphael Hertzog]

Hi,

On Mon, 18 May 2020, Holger Levsen wrote:
> I'd like to update the copyright statements in d/changelog and and
> source/index.rst and bring them in sync as well. Thus I have prepared
> the following diff.
> 
> I'd appreciate a quick review and possible corrections from you!

Fine for me.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Converting dev-ref to use rST

[Raphael Hertzog]

Hi,

On Mon, 08 Apr 2019, Sean Whitton wrote:
> I am considering to working to convert dev-ref to rST+Sphinx this
> summer.  I would like to start a discussion about doing that.  The
> main things that I need to learn from this discussion are:

I just want to point out that contrary to the Debian policy (which had no
translations when it got converted), dev-ref does have a bunch of
translations and I wonder whether there's a way to convert the translated
docbook with your same process and somehow match the various strings
together to update PO files...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Raphael Hertzog]

Hi,

On Mon, 27 Aug 2018, Sean Whitton wrote:
> On Mon 27 Aug 2018 at 12:58PM +0200, Raphael Hertzog wrote:
> > Or you could have read dh_linktree's manual page and see that you can
> > use "replace" instead of "deduplicate" to get a weak dependency.
> 
> I did read this -- unfortunately, though, it would not help make
> debian-policy installable on stretch, which was the original bug
> reporter's problem.

Ok, sorry for having commented too hastily.

(But this is the kind of thing which makes me believe that we go
too far in the avoid duplicating code, so much energy spent for
almost no gain)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Raphael Hertzog]

Hi,

On Sat, 25 Aug 2018, Sean Whitton wrote:
> Urgh.
> 
> I am reluctantly (yet gratefully!) working on implementing Ian's
> substvar hack.

Or you could have read dh_linktree's manual page and see that you can
use "replace" instead of "deduplicate" to get a weak dependency.

$ git diff
diff --git a/debian/debian-policy-ja.linktrees 
b/debian/debian-policy-ja.linktrees
index bb8ef9b..74aef4c 100644
--- a/debian/debian-policy-ja.linktrees
+++ b/debian/debian-policy-ja.linktrees
@@ -1 +1 @@
-deduplicate /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/ja/policy.html/_static/
+replace /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/ja/policy.html/_static/
diff --git a/debian/debian-policy.linktrees b/debian/debian-policy.linktrees
index 88fadfd..ea76805 100644
--- a/debian/debian-policy.linktrees
+++ b/debian/debian-policy.linktrees
@@ -1 +1 @@
-deduplicate /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/policy.html/_static/
+replace /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/policy.html/_static/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy

[Raphael Hertzog]

Hi,

On Tue, 21 Aug 2018, Russ Allbery wrote:
> Perl folks, the short version is that Lintian wasn't actually checking for
> scripts that used /usr/bin/env perl, so our check when we closed #683495
> was bogus.  Lintian has now changed based on Policy, and it looks like
> there were around 2,000 scripts in Debian that were using the /usr/bin/env
> perl form.
> 
> Any feelings about where we should go from here?

Yes, relax the requirement to a "should" again and downgrade the severity
of the lintian tag to a warning, but get #904409 implemented so that the
vast majority of packages maintainers have nothing to do to get it right.

> I do feel like allowing either based on the whim of the packager is just
> kind of bad.  It produces inconsistent behavior to no real benefit for
> anyone.  If you install a Perl earlier in your PATH, you get totally
> unpredictable behavior, and everyone will be unhappy half the time.

Ack, IMO the decision was correct but the tooling was not ready for this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Raphael Hertzog]

Hello,

On Fri, 04 Aug 2017, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

Yes, that's entirely in the scope that I intended to give to
tracker.debian.org. As Paul already pointed out, I started a
DEP on this a long time ago (altough it's broader in scope):
http://dep.debian.net/deps/dep2/

> For legacy purposes, the Maintainer field would then list ${source}@tra
> cker.d.o and the Uploaders field could be removed.

While storing the maintainer information in tracker is far from being
done, I actually worked on various steps to make it possible to have
a generic maintainer address like "@packages.debian.org" (like I
ensured that the packages.debian.org email aliases do not include
packages.debian.org email addresses to avoid loops [1]).

I think the only missing step is some sort of logic to drop duplicate
emails that we would currently get through the tracker if we do not change
anything in dak or the BTS or other scripts that are currently mailing
both the maintainer and the tracker directly.

In the future, I would like to be able to also use “team+...@tracker.debian.org“
so that it's automatically tagged as being part of the corresponding team
and so that the associated mails are sent to the team subscribers. But
here again we have quite some work to do.

FWIW, I just tried to use z...@packages.debian.org as maintainer for my zim
package, we will see if my analysis is right and if I only get a few
duplicates. We will have to fix lintian too because I just see this:

E: zim source: maintainer-address-causes-mail-loops-or-bounces Zim Package 
Maintainers 

And the tag is not overridable and it's fatal for dak. Ansgar, do you
feel like disabling that auto-reject tag temporarily so that I can upload my
test package ?

Cheers,

[1] 
https://anonscm.debian.org/cgit/webwml/packages.git/commit/?h=debian-master&id=5f4f27920e996e521d32dfb5a9693a09348d18d5
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Debian Policy and Publican

[Raphael Hertzog]

Hello Russ,

On Sun, 30 Apr 2017, Russ Allbery wrote:
> Thanks to a ton of hard work by Guillem, finishing up the work that Osamu
> Aoki started, debian-policy Git head is now DocBook.  It's currently using
> xsltproc and dblatex to generate its output (and my plan is to proceed
> with that for the near-term).  Howerver, this now opens up the possibility
> of using better markup from the full suite of available DocBook markup,
> and to use other DocBook-aware publishing platforms like Publican if they
> produce better output.
> 
> If you still think that Publican would potentially be useful for this, I'd
> love to chat!

I still believe that Publican can be useful, yes, for two reasons:
- its HTML output is very nice-looking
- it makes it easy to manage translations (this might or might not be
  relevant)

For the PDF output, I find the dblatex output to be cleaner than the
Publican one (which uses wkhtmltopdf so relies on HTML output and Webkit
HTML renderering, its output is pretty but not perfect if you want book-like
quality). But if you want a better PDF, you have to provide a custom LaTeX
stylesheet. That's what I do for the Debian Handbook.

Feel free to check the debian-handbook source package to see how I use
Publican in combination with dblatex (build/build-pdf is the starting
point).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#823348: Limit the strongest dependencies on supplemental -doc packages

[Raphael Hertzog]

On Sat, 31 Dec 2016, Russ Allbery wrote:
> Looks reasonable to me.  Seconded.

Seconded.

> 
> > diff --git a/policy.sgml b/policy.sgml
> > index 404dc73..421e0d1 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -10699,6 +10699,18 @@ END-INFO-DIR-ENTRY
> > 
> >  
> > 
> > + If package is a build tool, development tool,
> > + command-line tool, or library development package,
> > + package (or package-dev in the case of a
> > + library development package) already provides documentation in
> > + man, info, or plain text format, and package-doc
> > + provides HTML or other formats, package should declare
> > + at most a Suggests on package-doc. Otherwise,
> > + package should declare at most a Recommends on
> > + package-doc.
> > +   
> > +
> > +   
> >   Additional documentation included in the package should be
> >   installed under /usr/share/doc/package.
> >   If the documentation is packaged separately,
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#829367: Please add virtual-mysql-* packages to the official list of virtual packages

[Raphael Hertzog]

On Sat, 31 Dec 2016, Russ Allbery wrote:
> > The list and descriptions:
> 
> > virtual-mysql-client - A MySQL database compatible client package
> > virtual-mysql-client-core- A MySQL database compatible client core 
> > package
> > virtual-mysql-server - A MySQL database compatible server package
> > virtual-mysql-server-core- A MySQL database compatible server core 
> > package
> > virtual-mysql-testsuite  - A MySQL database compatible test suite 
> > package
> 
> I second adding these virtual packages (so we need another second to apply
> them to Policy).

Seconded.


-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Raphael Hertzog]

On Sat, 31 Dec 2016, Russ Allbery wrote:
> >>[…]
> >>
> >>The first paragraph of the control file contains information about the
> >>source package in general. The subsequent sets each describe a binary
> >>package that the source tree builds. All the binary packages have a
> >>corresponding paragraph, except for the possible automatic debug
> >>packages that do not require one.
> 
> > There may be better ways to phrase this, but I think there is still a
> > need for some clarification about this.
> 
> Seems reasonable to me.  Seconded.

Seconded.

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#793493: debian-policy: Update dpkg-architecture flags information

[Raphael Hertzog]

On Sat, 31 Dec 2016, Russ Allbery wrote:
> These all look good to me.  Seconded (and quoted below for the convenience
> of others who may want to review and second).

Seconded.

> 
> > From 0bc030c417adfa7ca50944c918101dd9ce62bebb Mon Sep 17 00:00:00 2001
> > From: Guillem Jover 
> > Date: Fri, 24 Jul 2015 17:17:58 +0200
> > Subject: [PATCH 1/2] Update information about DEB_TARGET_* variables
> 
> > These are used to support building cross-compilers. Introduced in
> > dpkg 1.17.14.
> > ---
> >  policy.sgml | 16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> > diff --git a/policy.sgml b/policy.sgml
> > index 404dc73..72a2505 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -2175,9 +2175,16 @@ zope.
> >   the architecture on which debian/rules is run and
> >   the package build is performed.  The host architecture is the
> >   architecture on which the resulting package will be installed
> > - and run.  These are normally the same, but may be different in
> > + and run.  The target architecture is the architecture of the
> > + packages that the compiler currently being built will generate.
> > + These are normally the same, but may be different in
> >   the case of cross-compilation (building packages for one
> > - architecture on machines of a different architecture).
> > + architecture on machines of a different architecture), building a
> > + cross-compiler (a compiler package that will generate objects for
> > + one architecture, built on a machine of a different architecture)
> > + or a Canadian cross-compiler (a compiler that will generate
> > + objects for one architecture, built on a machine of a different
> > + architecture, that will run on yet a different architecture).
> > 
> >  
> > 
> > @@ -2205,8 +2212,9 @@ zope.
> > DEB_*_GNU_TYPE)
> >   
> >   where * is either BUILD for specification of
> > - the build architecture or HOST for specification of the
> > - host architecture.
> > + the build architecture, HOST for specification of the
> > + host architecture or TARGET for specification of the
> > + target architecture.
> > 
> >  
> > 
> > -- 
> > 2.5.0.rc2.392.g76e840b
> 
> 
> > From 70aaad841a5067db2737ea658532eb92d9376888 Mon Sep 17 00:00:00 2001
> > From: Guillem Jover 
> > Date: Fri, 24 Jul 2015 17:19:06 +0200
> > Subject: [PATCH 2/2] Update information about DEB_*_ARCH_* variables
> 
> > Mention DEB_*_ARCH_BITS and DEB_*_ARCH_ENDIAN. Introduced in dpkg 1.15.4.
> > ---
> >  policy.sgml | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> > diff --git a/policy.sgml b/policy.sgml
> > index 72a2505..b7f0464 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -2197,6 +2197,12 @@ zope.
> > DEB_*_ARCH_CPU (the Debian CPU name)
> > 
> > 
> > +   DEB_*_ARCH_BITS (the Debian CPU pointer size in bits)
> > +   
> > +   
> > +   DEB_*_ARCH_ENDIAN (the Debian CPU endianness)
> > +   
> > +   
> > DEB_*_ARCH_OS (the Debian System name)
> > 
> > 
> > -- 
> > 2.5.0.rc2.392.g76e840b
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Bug#825992: developers-reference: Italian Translation

[Raphael Hertzog]

On Sun, 12 Jun 2016, Hideki Yamane wrote:
>  And, policy maintainers, could you give me a permission to release it
>  as 3.4.18, please? If none of you would say any objection for some days,
>  I'll add me as Uploaders and upload it.

I don't think you need any extra permission for this. The
developers-reference has always been relatively open in terms of
maintenance provided that changes to the text are properly peer-reviewed
before being committed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#759492: File conflicts between /bin and /usr/bin

[Raphael Hertzog]

On Mon, 07 Mar 2016, Ansgar Burchardt wrote:
> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).
> 
> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.
> 
>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
> 
>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

I also second this improved wording or any other wording in the same spirit.

I agree it's better than the initial wording. Though it would be good to
list the most common values of "{path}" (and you want to use 
path in docbook instead of {path}).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#759492: File conflicts between /bin and /usr/bin

[Raphael Hertzog]

On Sat, 05 Mar 2016, Bill Allombert wrote:
> So to recap, Marco proposal is
> 
> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..74f0a3b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8508,6 +8508,21 @@ fi
> renamed.  If a consensus cannot be reached, both
> programs must be renamed.
>   
> +
> + 
> +   To support merged /usr systems, packages must not install a
> +   file in /usr/bin with the same name as a file in
> +   /bin or a file in /usr/sbin with the
> +   same name as a file in /sbin.
> +   If such a compatibility symlink is needed then it must be
> +   managed in the maintainer scripts in a way that will not break
> +   when e.g. /usr/bin and /bin are the
> +   same directory.
> +   Packages must not install a file in /usr/lib (or
> +   one of its subdirectories) with the same name as a file in
> +   /lib (or the corresponding subdirectory).
> + 
> +
>   
>Binary executables must not be statically linked with the GNU C
>library, since this prevents the binary from benefiting from
> 
> Who is seconding this ?

Seconded.


-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#798476: debian-policy: don't require Uploaders

[Raphael Hertzog]

On Thu, 10 Sep 2015, Raphael Hertzog wrote:
> No, we should stop filing O bugs.  Instead we have just come up with a
> nice definition of an orphaned package, it's called the
> no-human-maintainer lintian tag:
> https://lintian.debian.org/tags/no-human-maintainers.

Sorry, the correct link is obviously with .html at the end:
https://lintian.debian.org/tags/no-human-maintainers.html 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#798476: debian-policy: don't require Uploaders

[Raphael Hertzog]

Hi,

On Thu, 10 Sep 2015, Charles Plessy wrote:
> if I remember well, this policy was set because some developers were
> (rightfully in my opinion) annoyed when the Maintainer field is a moderated
> mailing list and there is no Uploader field.

I don't think that this requirement makes sense. They can be rightfully annoyed
but it doesn't make sense to keep an outdated Uploaders field just to
please people so that they can mail people who no longer care about the
package.

If you need to find out someone who has some interest in the package, you
can always check who uploaded it last (or in the last X months).

IMO the hard requirement comes more from the fact that we don't like package
with no maintainer... those are effectively orphaned and should be up for
adoption by other maintainers.

> Perhaps this could be done by saying that as an exception to the rule, 
> orphaned
> packages can use a mailing list as Maintainer, and adding a footnote 
> explaining
> that this mailing list does not need to be the QA team.

Yes, I believe that this is the correct approach.

On Wed, 09 Sep 2015, Iain R. Learmonth wrote:
> An O bug is still filed on the package, but the Maintainer field remains
> unchanged (the decision of whether or not to change it is left to the
> person making the upload, the team may want rid of the package).

No, we should stop filing O bugs.  Instead we have just come up with a
nice definition of an orphaned package, it's called the
no-human-maintainer lintian tag:
https://lintian.debian.org/tags/no-human-maintainers.

We can stop the busy work of filing O bugs and point people who wants to
adopt packages to that page.

> Any package that has no named person in the Maintainer field or
> Uploaders field should be considered orphaned and a free candidate for
> someone to come along and file an ITA.

Yes, they should be open for adoption (as part of the team ideally, except
when the team was the QA team), 0-day NMU, etc.

> The existing team in the Maintainer field of orphaned packages does not
> give an obligation for the adopter to maintain the package within that
> team, but until it is adopted the team will still recieve bug
> notifications, etc. and is likely to be more knowledgable on the package
> than the QA team in general.

While there's no obligation, we should not encourage people to take such
packages out of team maintainance. Having a team fallback is always better
than not having one.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: where to maintain DEP8^W autopkgtest spec now

[Raphael Hertzog]

Hi,

On Thu, 24 Jul 2014, Charles Plessy wrote:
> PS: for dep.debian.net, I am stuck with the fact that there does not seem to 
> be
> an appropriate place for whole-DD-writable ikiwiki websites in Debian, and I

Can you remember us why alioth is no longer suitable ?

AFAIK it still has everything required to setup that kind of thing. And
it's now again on a single machine IIRC.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140724144943.ga1...@x230-buxy.home.ouaza.com

Re: improvements to the Developers Reference maintenance workflows?

[Raphael Hertzog]

Hi,

On Tue, 08 Jul 2014, Steve Langasek wrote:
> If we're going to have this in collab-maint, I think it's probably important
> to ensure that git commits are announced on debian-policy.  Could someone
> set this up?

Done.

On Tue, 08 Jul 2014, Bill Allombert wrote:
> Personnaly, I would prefer if they were sent to a dedicated mailing list.
> There is enough traffic on debian-policy as it is.

The average number of commits on developers-reference is very low, and
those mails are easy to filter with procmail if they are noise for you.

Thus I went ahead.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140708185516.ga4...@x230-buxy.home.ouaza.com

Re: improvements to the Developers Reference maintenance workflows?

[Raphael Hertzog]

Hi,

On Thu, 03 Jul 2014, Lucas Nussbaum wrote:
> An easy improvement is to switch to Git and collab-maint, and to
> announce that direct commits of consensual changes are OK.
> After that, we could call for help.
> Raphael, Marc, are you fine with that?

Yes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140703133234.gd1...@x230-buxy.home.ouaza.com

Re: improvements to the Developers Reference maintenance workflows?

[Raphael Hertzog]

(adding debian-doc to the cc)

Hi,

On Thu, 19 Jun 2014, Paul Wise wrote:
> Some of you may be aware there has been a discussion about devref on
> debian-private and debian-project, the threads started here:
> 
> <20140613131135.ga7...@x61s.reliablesolutions.de>
> https://lists.debian.org/20140618120859.ga7...@jwilk.net

Yes, I saw it and wanted to chime in... but I did not find the time
and motivation and wanted to see where the discussion would lead.

> Switch to a different documentation format that more people are able to
> write, this probably too much work to be useful though.

I don't think this is the real blocker. People should be free to submit
content without markup (or with wiki-like markup), it's easy to integrate
the content and add the small bits of docbook markup.

> Switch from svn to git. Many people prefer git to svn, this might
> increase the amount of people willing to contribute.

I would definitely welcome this, I'm using git-svn anyway currently.

The debian-doc group uses svn for historic reasons but I don't think
that anyone would oppose switching the devel-ref (which has always been
treated in a special way). I don't know if the debian-doc alioth project
granted commit rights to debian developers by default. But, if not, we
should certainly do it.

> Publish directly to the website on each git push. This would make the
> devref copy on the website less stale. An alternative might be weekly or
> monthly releases to the archive.

We used to do this but:

1/ the www team wanted to get rid of this because maintaining a proper
build environment was causing regular problems (eg due to version skew
between stable (the www build environment) and unstable (the package build
environment)).

2/ the supplementary delay was seen by some people as a good thing so that
changes can be better reviewed before being pushed to the wide public

3/ some believe that the content of the package is as important as the content 
of the
website and we should release more often to avoid those delays

So yes, we should do monthly releases (weekly is a bit too much IMO).

> Add an ACL so that all Debian members are able to commit (or move to
> collab-maint). This would lower the bar for contributions, allow trivial
> issues to be fixed easily and reduce change latency.

I have no problem with this but others have had with this way of working.

With Andreas Barth, while we were disagreeing about the way to maintain
this package, we agreed that direct commit was not really acceptable and
that each patch should be sent to the BTS for review. Explicit ACK or
lack of opposition could then be used to commit the changes.

Steve Langasek was also strongly in favor of some prior review because the
document ought to define the best practices for the project and changes
without buy in from the project at large would be detrimental.

> Call for help so that more people get involved and more issues get
> fixed. This could be a single mail to d-d-a or a DevNews entry. This
> should probably only happen after some improvements are made.

Yes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140619070517.ga21...@x230-buxy.home.ouaza.com

Bug#751489: Gandi discount available, again

[Raphael Hertzog]

Control: retitle -1 Replace section about goodies for developers with pointer 
to wiki page
Control: tags -1 - patch

On Tue, 17 Jun 2014, Jan Niehusmann wrote:
> More information is available at
> https://wiki.debian.org/MemberBenefits
> 
> I think section 4.13.2 (or even the whole section 4.13) should be replaced
> with a pointer to that wiki page.

Agreed. Updating the bug title and tags accordingly.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140617155238.gb3...@x230-buxy.home.ouaza.com

Bug#738607: developers-reference: Change contact preferences to the security-team in 5.8.5.

[Raphael Hertzog]

On Tue, 11 Feb 2014, Salvatore Bonaccorso wrote:
> At the Security team sprint meeting in Essen we concluded that working
> trough the request tracker does not fit well with our workflows when
> handling issues. We would thus like to change the paragraph on how to
> contact the security-team in the developers-reference in paragraph
> 5.8.5. The change consist to make the email contact the only point of
> contact removing the reference to the Request Tracker.
> 
> Attached patch addresses this, could you apply it for your next update
> of the dev-ref?

Thanks, applied in svn.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221092851.ga28...@x230-buxy.home.ouaza.com

Re: Updating the Policy Editors delegation

[Raphael Hertzog]

On Mon, 06 Jan 2014, Russ Allbery wrote:
> Ian Jackson  writes:
> 
> > This is all very well but I think de jure they aren't a delegated team,
> > and the distinction is defined in the constitution.  This is not
> > trivially bypassable, because a delegated team is one who derives their
> > powers from the DPL and the constitution limits the powers of the DPL.
> 
> I believe that deciding on the mechanisms and machinery whereby the
> project as a whole will work out its technical policy (as opposed to
> disputes over the contents of that policy itself) falls nicely under 5.1.4
> and 5.1.9, particularly the latter.

Agreed, the role of policy editors is to maintain a document. The fact
that it's also uploaded in Debian as a package is just a technicality.

Would ftpmasters stop being a delegated team the day where they package
dak again ? I don't think so.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106180200.ga2...@x230-buxy.home.ouaza.com

Bug#728200: debian-policy: force build tools to ensure source trees are build-ready

[Raphael Hertzog]

On Mon, 04 Nov 2013, Bill Allombert wrote:
> Such policy change should have been proposed before --commit was implemented.
> dpkg is supposed to follow policy not the other way round.

No, the policy doesn't dictate everything top-down. Large part of it are
built on top of existing practices that it merely formalizes.

This change was discussed on -devel. Please stop looking for problems
where there are none.

http://lists.debian.org/20110529085303.ga17...@rivendell.home.ouaza.com

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104134617.ga18...@x230-buxy.home.ouaza.com

Bug#728200: debian-policy: force build tools to ensure source trees are build-ready

[Raphael Hertzog]

On Tue, 29 Oct 2013, Russ Allbery wrote:
> > In general, when using source format 3.0 (quilt) or later, running
> > `dpkg-source -x' on a source package will produce the source of
> > the package, ready for editing.  This will allow one to make
> > changes and run `dpkg-buildpackage' to produce a modified package
> > without taking any additional steps.  (Note, however, that such
> > modifications must be made in the form of a new patch using the
> > `quilt' system with QUILT_PATCHES=debian/patches, otherwise
> > `dpkg-source -b' will fail.)
> 
> I believe the last part is not entirely correct.  dpkg-buildpackage will
> detect the source modification and will generate a patch for you when you
> do the build.

It will generate the patch in /tmp/ but it will also fail in the default case. I
know you're a user of --single-debian-patch which explains that you don't
encounter this case.

To avoid unexpected changes, we changed this a long time ago (dpkg 1.16.1)
when we introduced "dpkg-source --commit" to actually record the changes
in a new patch.

Maybe the whole processe should be documented as:
1/ dpkg-source -x
2/ do the changes
3/ dpkg-source --commit
4/ dpkg-buildpackage

> With the removal of the parenthetical, this looks good to me.  Seconded.

With the above clarification made, seconded, too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104071739.gb30...@x230-buxy.home.ouaza.com

Bug#720507: .dsc field for dgit

[Raphael Hertzog]

Hi,

On Fri, 23 Aug 2013, Ian Jackson wrote:
> I think this is starting to convince me that this means I should be
> using a different kind of field name.  This isn't really suitable.  In
> particular, it shouldn't interact with any deliberate setting of Vcs-*
> by the maintainer.

Yes, "Dgit-Commit" or "Dgit-Ref" or something like that seems to be
cleaner.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130823090949.ga12...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

On Mon, 22 Jul 2013, Charles Plessy wrote:
> Nevertheless, please let me try to refocus on the question of whether
> the Policy can be updated or not.

I believe we can update the policy whatever the status of this specific
bug.

> Here is what is written in the Policy about "postinst configure":
> 
> The files contained in the package will be unpacked. All package
> dependencies will at least be unpacked.

You're missing the important sentence that follows: “If there are no
circular dependencies involved, all package dependencies will be
configured.”

> I propose to go ahead with the following:
> 
> postinst triggered
>   "trigger-name trigger-name ..."
> 

My suggestion:

postinst configure was already run and the dependencies ought
to be configured. However, dpkg currently suffers of a bug which means
that postinst triggered can be called while some dependencies
are being upgraded (see bug http://bugs.debian.org/671711";
name="671711">). You should thus only rely on the fact that the
dependencies are at least unpacked and were already configured once
(similar to what Pre-Depends ensures for preinst
maintainer scripts).

> I would like to go ahead and close this bug.  If Raphaël confirms that he 
> still
> seconds the patch,  I would much appreciate if I could either have support or
> actionable objection from others (preferably in the form of "unless X is done,
> the patch should not be applied", rather than "it would be good to do Y").

I maintain my second provided that you fix the above.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722070059.gb24...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

On Sat, 20 Jul 2013, Charles Plessy wrote:
> Can you explain what the bug is and what the correction will be ?  Because I

The bug is that triggers are run while the dependencies of the triggered
package are not satisfied. The fix is not to do that and wait until those
dependencies are satisfied (but guillem mentionned that it also needs some
cycle breaking code).

> The misleading point is "just like packages in installed".  In my
> understanding, when a package is upgraded, the packages that depend on it stay
> in the "Installed" state while the new version of the upgraded package is
> unpacked and configured.  Not just the triggers, but also any other command 
> not
> related to the dpkg or apt session that would happen to run at that time can
> fail if they strictly require a function that is not available between unpack
> and configure.

That's true but it's not really comparable. "postinst triggered" ought to
work like "postinst configure" and there you have the guaranty that the
dependencies are configured.

> I do not see any other solution than applying the same restrictions on
> "postinst triggered" as for "postinst configure".  (PS: after reading the
> thread again, I just noticed that this also what you wrote in #671711#68).

I did not write that. On the contrary, re-read:

“The problematic fix is to ensure the same requirements for "postinst
triggered" as for "postinst configure". But we could enforce some
requirements that would probably solve the issues we saw without
introducing cycles.”

There are no "restrictions" for "postinst configure" (you can rely on
dependencies — except if you have a dependency cycle) and there should be
no restrictions for "postinst triggered". But right now, dpkg doesn't
ensure anything. And instead of nothing checked by dpkg, I suggested to
ensure some requirements nevertheless but which are less demanding than
those used by "postinst configure".

> (PPS: By the way, apart from Manoj's excellent diagrams at
> , is 
> there
> an extensive documentation on how package upgrades are handled by APT and 
> Dpkg ?)

I know https://wiki.debian.org/MaintainerScripts too but that's all.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130721193652.ga19...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

Hi,

On Thu, 18 Jul 2013, Charles Plessy wrote:
> After reading #671711 and /usr/share/doc/dpkg-dev/triggers.txt.gz, my
> impression is that a package can not become "Unpacked" and keep a list of
> pending triggers, because of the following statements in triggers.txt:
> 
>  1) Pending triggers are marked "never" for "Unpacked" packages in the 
> overview
> table.
> 
>  2) The section "Details - triggered package" mentions that "packages in
> ‘config-failed’ or worse are never considered to have lists of pending
> triggers".  (Where config-failed means Half-Installed).  In my 
> understanding of
> Dpkg states, Unpacked is "worse" than Half-Installed.
> 
> There are two consequences to this:
> 
>  - "postinst configure" should do at least everything needed by
>"postinst triggers", since in the situations where triggers are dropped,
>the package is in a state that ensures that "postinst configure" will be 
> run.

Yes, that's pretty important. I haven't checked if this was already
documented in your patch, but it definitely is a clear rule in the
/usr/share/doc/dpkg-dev/triggers.txt.gz.

>  - we could write in section 6.5 of the Policy that for "postinst triggers"
>the requirements are the same as for "postinst abort-*":
> 
>  "The files contained in the package will be unpacked. All package
>  dependencies will at least be "Half-Installed" and will have previously 
> been
>  configured and not removed. However, dependencies may not be configured 
> or even
>  fully unpacked in some error situations."

Why not, but then please add a footnote explaining that this ought to be
temporary until the dpkg bug gets fixed. Because it's not really a
satisfactory situation.

> I understand that changes in dpkg can enchance the mechanism to use triggers,
> thus reducing the risk of having bugs, but I think that in #671711, dpkg is
> following the specification, unless it failed to clear the list of pending
> triggers when monodoc-browser became unpacked when it was upgraded.

The documentation says "Packages in t-awaited and t-pending demand
satisfaction of their dependencies just like packages in installed.".

This is the part that is not respected in the above bug. So no, it's not
really following the specification.

> Is that correct ?  If yes, then I propose to go ahead and apply an improved
> patch to the policy that mentions the restrictions and requirements on
> "postinst triggers", because it represents an enhancement to the existing
> documentation.

Definitely.

jessie development is live, we want to draw the attention of people to
review their triggers and do the right thing.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130718070044.gc29...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

On Thu, 18 Jul 2013, Charles Plessy wrote:
> Le Thu, Jul 18, 2013 at 08:55:20AM +0900, Charles Plessy a écrit :
> > 
> > regarding “noawait” triggers, the patch already contains the following, 
> > which
> > is new and improved compared to the existing documentation.
> > 
> > The *-noawait directives should be used unless the
> > packages awaiting triggers can not satisfy Depends
> > relationships until the triggers have been processed.
> 
> By the way, are the “noawait” triggers guaranteed to be executed only after 
> the
> triggering package has entered the "Installed" state, or can they be executed
> at the same time of other triggers as well ?

There's no such guaranty. A package that triggers another package only
knows that the triggers will be processed at some point in the future. It
doesn't know if if will before or after its own configuration (the
"noawait" doesn't change anything here except that the trigger requirement
is not recorded).

Even with traditional triggers, it's possible that dpkg will configure a package
before processing the triggers that it awaits. What this means is just
that the end status will be "Triggers-Awaited" instead "Installed".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130718065109.gb29...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

Hi,

On Wed, 17 Jul 2013, Charles Plessy wrote:
> About the problem of triggers being called with Depends not satisfied, can you
> give more explanations or suggest some text for the warning ?  Would it be
> enough to add a notice that the triggered postinst script may be called when
> the package is "Unpacked", which is a state that does not require that the
> packages that are depended on are configured ?

Julien is referring to this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671711

It might be fixed for jessie, at least I hope so, but he seems to doubt
it.

> Also, if you think that triggers will give us problems for the Jessie release,
> may I suggest that you give it a broad audience on debian-devel ?  As a
> maintainer of a package that has triggers, I am definitely interested to learn
> if there is something I should give particular attention there.

One of the main things to do is to switch as many packages as possible to
use the interest-noawait directive when possible.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717072719.gg3...@x230-buxy.home.ouaza.com

Bug#709218: developers-reference: adjust versioning convention note for security updates

[Raphael Hertzog]

On Tue, 21 May 2013, Salvatore Bonaccorso wrote:
> In #685646 the advise for versioning for {stable,testing}{,-security}
> uploads was adjusted. In [1] there is a missing bit for it refering to
> the older convention +codename1. I tried to address this change in
> attached patch.

Thanks, applied.

-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130522084257.gf12...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

Hi,

On Thu, 16 May 2013, Charles Plessy wrote:
> Guillem recently posted on debian-devel about "noawait" triggers, and I would
> like to send a link to the patch to the Policy once it gets futher
> proof-reading and seconds.  Or if it takes time, shall I point to this bug log
> on -devel ?

I don't see any harm to mentioning it right now. And maybe point Ian
Jackson to it, he might want to review and second it...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130516113255.gg14...@x230-buxy.home.ouaza.com

Bug#707851: debian-policy: soften the wording recommending menu files

[Raphael Hertzog]

(Your last mail was not sent to the BTS but to the ML directly)

On Tue, 14 May 2013, Wouter Verhelst wrote:
> I didn't mean to imply someone other than the relevant UI maintainers
> would need to write code for this to happen; we could simply add some
> wording along the lines of
> 
>   packages that install desktop files must emit the
>   ``desktop-files-installed'' trigger from their postinst (e.g., by
>   running ``dpkg-trigger desktop-files-installed''), so that user
>   interfaces which don't support desktop files directly can listen to
>   this trigger and update their menus.

A file trigger on /usr/share/applications does exactly that. There's no
need to formalize anything more IMO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130515062310.ga30...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

Hi,

On Sun, 12 May 2013, Charles Plessy wrote:
>   
> The *-noawait directives should be used unless the 
> packages awaiting triggers can not satisfy Depends
> relationships until the triggers have been processed.  
> In that case, the interest or activate 
> directives
> should be used, as they will put the triggering packges in the
> "Triggers-Awaited" state, which does not satisfy dependencies.
> Note that pakcages unnecessarly entering this state can cause the

s/pakcages/packages/

> early processing of triggers or even dependency loops.
>   
> 
> I also added "through the interst or activate directives"
> after "When a configured package activates a trigger".
> 
> I applied the other changes you proposed as well, with minor rewording:
> 
> -   dpkg keeps a list, Triggers-Awaited of
> -   interested packages whose trigger processing is awaited.  Every
> +   dpkg keeps a list of interested packages whose 
> trigger
> +   processing is awaited, which is stored in the
> +   Triggers-Awaited field in dpkg's status database.  Every
> 
> I attached an updated version of the patch.

Thanks, I agree that your improved wording is better. Seconded.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130512080917.gb14...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

Hi Charles,

On Sat, 11 May 2013, Charles Plessy wrote:
> I think that I took care of all of your comments.
> 
> Here is an updated patch.  Among the changes, it introduces
> sub-section to make the information easier to digest.

Thank you for the work! I have a few fixes and suggestions but otherwise
it looks mostly ready.

So seconded with the few suggestions below.

> +   
> + The triggers control file contains one directive per
> + line.  Leading and trailing whitespace, everything after the first
> + hash character (#) on any line, and empty lines are 
> ignored.
> + The following directives are supported.
> + 
> +   interest trigger-name
> +   interest-noawait trigger-name
> +   
> + Specifies that the package is interested in the named trigger.
> + The interest-noawait variant does not put the
> + triggering packages in the "Triggers-Awaited" state.
> +   
> +
> +   activate trigger-name
> +   activate-noawait trigger-name
> +   
> + Specifies that changes to this package's state will activate the
> + named trigger.  The activate-noawait variant does not
> + put this package in the "Triggers-Awaited" state.
> +   
> + 
> +   

Here I would add a small paragraph recommending the usage of the -noawait
variants unless they are strictly required.

The *-noawait directives should be used by default to avoid
putting packages in the "Trigger-Awaited" status. Packages should only end up
in this intermediary status when they are effectively broken until the
awaited triggers have been processed. A package in "Trigger-Awaited" does
not satisfy dependencies, for this reason an excessive and injustified amount 
of package
in this status can lead to early processing of triggers or even to dependency
loops.

> +   
> + When a configured package activates a trigger, its state becomes
> + "Triggers-Awaited" instead of "Installed".  For this package,
> + dpkg keeps a list, Triggers-Awaited of

missing comma after "Triggers-Awaited", but I would rather rewrite it
like this:

keeps a list of interested packages whose trigger processing is awaited
(that list is stored in the Triggers-Awaited field in dpkg's status
database)

> + interested packages whose trigger processing is awaited.  Every
> + package in this list either has a nonempty list of pending
> + triggers, or is in "Half-Configured" or worse.  When a package in
> + the state "Triggers-Pending" becomes "Installed", "Config-Files" or
> + "Not-Installed", its entry is removed from the
> + Triggers-Awaited lists of other packages.
> +   
> +
> +   
> + When a trigger is activated, the state of every interested package
> + becomes "Triggers-Pending".  For each package, dpkg
> + keeps a list, Triggers-Pending, of triggers whose
> + processing is pending.  Repeated activation of the same trigger has

Same suggested rewrite as above here.

> + no additional effect.  In general a trigger will not be processed
> + immediately when it is activated; processing is deferred until it is
> + convenient.
> +   
> +
[...]
> + Packages in "Half-Configured" or worse never have pending triggers.
> + A package is only guaranteed to become notified of a trigger
> +activation if it is continuously interested in the trigger, and 
> never
> +in "Half-Configured" or worse.  A package whose postinst is 
> being run

weird spacing here

> + can however acquire pending triggers during that run (ie, a package
> + can trigger itself).
> +   
> +
> +   
> + However, if such a package (between "Half-Installed" and
> + "Half-Configured" inclusive) declares some trigger interests then 
> the
> + triggering packages will await their configuration (which implies
> + completion of any necessary trigger processing) or removal.
> +   
> +
> +   
> + For this reason, the postinst scripts it must do whatever

s/it//

> + actions are necessary to deal with any trigger activations when they
> + are called with configure.
> +   
> + 
> +  
>  

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130511130925.ga21...@x230-buxy.home.ouaza.com

Re: Erroneous link in in Chapter 6

[Raphael Hertzog]

Hello,

On Thu, 18 Apr 2013, Tobias Wolter wrote:
> there's an outdated hyperlink in
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#helper-scripts
>  
> pointing to 
> http://arch.debian.org/arch/private/srivasta/
> which does not exists anymore.

Thanks, I dropped the paragraph with the broken link in the SVN
repository.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130428135403.gc28...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

On Wed, 10 Apr 2013, Russ Allbery wrote:
> Raphael Hertzog  writes:
> > On Fri, 15 Mar 2013, Charles Plessy wrote:
> 
> >> +Dpkg defines the folowing states for the packages.
> >> +
> >> +  Not-Installed
> 
> > I would use the precise states listed in dpkg(1), i.e. entirely in
> > lowercase. (same for all the states)
> 
> I thought Guillem requested we use the capitalized versions.  I think the
> capitalized versions stand out more and make it clearer that the expected
> meaning isn't necessarily the plain English meaning of the phrase.

Ok, but then we ought to be consistent and avoid usage of
config-files or config-failed and other similar mention
of states elsewhere.

BTW, I just notice that config-failed in the text was wrong and
should refer to "Half-Configured".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130410184707.ga16...@x230-buxy.home.ouaza.com

Bug#582109: debian-policy: document triggers where appropriate

[Raphael Hertzog]

Hi Charles,

On Fri, 15 Mar 2013, Charles Plessy wrote:
> I am still seeking comments for the attached patch, that describes Dpkg
> triggers.

Here are my comments. There's quite a bit of work left.

> >From 6a7fd0e49cb8dbd025771feb95c2dcafb408c1b8 Mon Sep 17 00:00:00 2001
> From: Charles Plessy 
> Date: Sat, 2 Mar 2013 22:48:04 +0900
> Subject: [PATCH] Document dpkg triggers.
> 
> Closes: #582109.
> ---
>  policy.sgml | 275 
> ++--
>  1 file changed, 268 insertions(+), 7 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index a41bc1f..c6e1a9e 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -900,9 +900,12 @@ zope.
>   the package.  Other control information files include
>   the symbols file
>   or shlibs file
> - used to store shared library dependency information and
> + used to store shared library dependency information,
>   the conffiles file that lists the package's
> - configuration files (described in ).
> + configuration files (described in ), and the
> + file triggers that lists the

"the triggers file"
(invert two words)

> + triggers that the package is interested
> + in.

the triggers file (see man deb-triggers) can contain "interest" directives
but also "activate" ones. So this needs to be reworded.

For example “the triggers file wich defines the package's interaction with
dpkg's trigger system”

> +   Dpkg defines the folowing states for the packages.
> +   
> + Not-Installed

I would use the precise states listed in dpkg(1), i.e. entirely in
lowercase. (same for all the states)

> @@ -4141,6 +4189,26 @@ Checksums-Sha256:
> from the package dependencies are not available is often the
> best approach.
>   
> +
> + postinst triggered
> +   "trigger-name trigger-name ..."
> + 
> +   Process one or more triggers that
> +   this package is interested in.  In case of failure the
> +   package's state becomes config-failed, so that the 
> trigger
> +   processing will not be attempted again until explicitly
> +   requested

I don't think that it's marked "config-failed" to not retry the trigger
processing. It's just that we need an error state and that config-failed
can be reused for this purpose precisely because anything done by trigger
processing is supposed to also be done during normal configuration (so it
is effectively retried on next configure).

“In case of failure the package's state becomes config-failed,
and the task associated to the trigger processing will be completed by
the postinst configure during the next package's configuration.”

> + When an interested package has more than one trigger and wants
> + to process them differently, the list of triggers can be can be

s/can be can be/can be/

> @@ -4694,6 +4762,198 @@ fi
>  
>   
>
> +
> +  
> + Dpkg triggers
> +
> + 
> +   A dpkg trigger is a facility that allows events caused
> +   by the installation, upgrade or removal of one package, and of
> +   interest to another package, to be recorded and
> +   aggregated, and processed later by the interested package.  This
> +   feature simplifies various registration and system-update tasks and
> +   reduces duplication of processing.
> + 

“dpkg triggers allows packages to monitor events caused by
the installation, upgrade or removal of packages. Monitoring packages are
said to be interested in some triggers. On the other side,
triggers must be activated to record the event notification on
the interested package. The latter is then said to have
pending triggers and the activating package (if any) is
said to await the processing of the trigger.

Thanks to this feature, it's easy to avoid duplication of processing logic
among packages by implementing it in one package and making sure that all
other packages rely on triggers to execute the wanted code.”

> + 
> +   Each trigger is named, and at any time zero or more packages may be
> +   interested in it.  Packages declare their interest by
> +   including a triggers file in their control archive.

The triggers file can contain "activate" directives too so I'd suggest
to be more explicit:

“For a package to declare its interest in a trigger, it must include one of
the interest directives in the triggers file in its
control archive.”

Then start a new paragraph describing the syntax of the triggers
file.

> +  This file contains one directive per line. Leading and trailing

Useless leading whitespaces on this line.

> +   whitespace, everything after the first hash character (#)

whitespaces ? (with "s")

> +   on any line, and empty lines are ignored.  The following directives
> +   are supported.
> +   
> + interest trigger-name
> + interest-noawait trigger-name
> + 
> +

Bug#703022: debian-policy: Appendix G: Diversion example faulty (doesn't work for conffiles)

[Raphael Hertzog]

Hi,

On Thu, 14 Mar 2013, Guillem Jover wrote:
> It should work way better than before, in part thanks the to the usage
> and bug reporting from MIT, but as you say there's still some wrinkles,
> which I plan on fixing for 1.17.x; in any case I'm always interested in
> any bug reports affecting these.

The major issue I had with this case is when you try to purge the
diverting package. On remove, you put back in place in the original
conffile and at that point dpkg should (but doesn't currently) forget
about the conffile in the diverting package. Otherwise on purge, you
actually remove the diverted conffile and you have no files left.

I don't know if that's part of your "known wrinkles". If not, I'll happily
open a bug report. Let me know.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130318075901.gb8...@x230-buxy.home.ouaza.com

Bug#685039: developers-reference: please document what is needed to reintroduce a package

[Raphael Hertzog]

Control: tag -1 pending

On Mon, 17 Sep 2012, Paul Wise wrote:
> I didn't see the comments from Charles Plessy as I wasn't subscribed to
> the bug and he did not CC me. I've attached a new version adopting his
> suggestions.

Patch applied with some tweaks (suggestion of David and also reformulation
of the introductory paragraph), thanks.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120917152317.ga8...@rivendell.home.ouaza.com

Bug#571776: document symbols

[Raphael Hertzog]

Hi,

On Sun, 12 Aug 2012, Russ Allbery wrote:
> I'm looking for seconds so that we can finally merge this monster.
> Presented as a diff since that was the request last time, but the branch
> has also been pushed to the Policy Git repository, so if you want to
> review it various other ways, you can start at:

Seconded.

Thank you very much for this work!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


signature.asc
Description: Digital signature

Bug#681289: debian-policy: Changelog and copyright should be package metadata

[Raphael Hertzog]

On Thu, 12 Jul 2012, Russ Allbery wrote:
> HOWEVER, I think putting those files in a clear place on the file system
> so that they can be easily read via a pager by the end user without using
> dpkg-query commands is not only mandatory for the transition period but
> mandatory permanently.  I would expect dpkg to do this.  That location
> could be in /var/lib/dpkg/copyright and /var/lib/dpkg/changelogs or some
> similar place, however.  (And arch-qualified when needed, of course.)

The current version of dpkg would put them in
/var/lib/dpkg/info/.{changelog,copyright} but we certainly don't want
end-users to rely on this.

Guillem introduced the --control-list and --control-show interfaces
precisely because we want a path and storage-agnostic way to access those
files. This enables us to change the way we store files in a more
efficient manner:
- we could compress the files with whatever compression method we want
- we could deduplicate identical files between multiple packages
  (copyright and changelog files within a source package tend to be identical)

If we want to keep the copyright/changelog files at their current location
(or in another official place), we should IMO create a new package that
will hook into dpkg --post-invoke and that would use dpkg-query
--control-show to retrieve those files and store them again where the user
wants (and conversely delete them during package removal).

BTW, dpkg-query --control-show already runs a pager if the output is a
terminal. In any case, I believe we should create dpkg --changelog
and dpkg --copyright as the canonical end-user interface.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713070059.go...@rivendell.home.ouaza.com

Bug#681289: debian-policy: Changelog and copyright should be package metadata

[Raphael Hertzog]

On Thu, 12 Jul 2012, Gerfried Fuchs wrote:
>Hi,
> 
> * Raphaël Hertzog  [2012-07-12 08:46:03 CEST]:
> > Both the changelog and the copyright files are stored with a package's
> > normal data (within data.tar in the .deb) but they are really package
> > metadata (that should be part of control.tar in the .deb).
> 
>  Are they?  I consider them documentation and expect them be next to the
> documentation.

Documentation can be meta-data. It's the fact that those documentation are
produced by Debian that qualifies them as meta-data (control.tar) and
not upstream data (data.tar).

>  And without any more than that statement I'm not really buying that it
> really would be a benefit?

The benefit I was referring too is purely in terms of performance.
Extracting control.tar.gz is faster than extracting data.tar.gz because of
its smaller size (at least in most non-trivial packages).

> > 2/ that programs that want to retrieve the changelog and/or copyright file
> >of an installed package should try to use "dpkg-query --control-show 
> > 
> >" and fall back to the usual path if that fails.
> > 
> >Those interfaces are available in wheezy's dpkg (>= 1.16.5).
> 
>  So that would force services to upgrade to wheezy as soon as the first
> such package lands in unstable, right?

It depends. What services are you thinking of? I expecte that programs
trying to access changelog/copyright of installed packages are mostly
end-user programs (so the "services" qualification seems weird).

> > 3/ that programs that want to retrieve the changelog and/or copyright file
> >of a .deb file should use dpkg-deb -I  " (or
> >look for the changelog/copyright file in the directory extracted
> >with dpkg-deb -e )
> 
>  "that programs" are also end-users, not?  Users expect the copyright
> and changelog information to be readily available to them.  How do you
> address their expectations?  Will they be in
> /var/lib/dpkg/info/package.{changelog,copyright}, so a symlink could
> help with that?

With the current implementation of dpkg, they will be there, yes.

But for end-users, I rather expect that we're going to create
"dpkg --changelog " that does the right thing for them (and same for
--copyright).

>  Last thing: policy is about document current practises, not about
> future possibilities.  Doesn't this bugreport come a bit early?

Some changes just can't be implemented without global coordination and
buy-in. The policy (and its associated process) is a way to ensure both.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713064818.gn...@rivendell.home.ouaza.com

Bug#679562: developers-reference: note that it is possible for Release Team to override urgency

[Raphael Hertzog]

Hi,

On Sat, 07 Jul 2012, Paul Gevers wrote:
> > On the typograhy side, it is very minor, but since you added a bullet point 
> > to
> > the list in 5.13.2, you can make the now previous bullet point finish by a
> > semicolon (see below), and the last bullet point finishing by a dot.
> 
> So, how about the attached patch?

Thanks, applied with minor tweaks. (And I dropped some supplementary
uninteresting information)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120709073135.ga3...@rivendell.home.ouaza.com

Bug#678712: developers-reference: Please make developers reference gender neutral

[Raphael Hertzog]

Hi,

On Mon, 25 Jun 2012, Russ Allbery wrote:
> The 15th Edition was published in 2003.  Since then, my personal
> impression is that opposition to generic "he" has hardened considerably
> and opposition to singular "they" has weakened somewhat.  Using "he" as a
> generic pronoun for a person of indeterminate gender is now generally
> considered inappropriate in manuals and documentation in the free software
> communities I've followed and the discussions I've seen, although there is
> the occasional hold-out.
> 
> I see there's now a 16th Edition out, but I don't personally have a copy.
> I'm curious whether it has changed its stance on singular "they" back to
> the stance in the 14th Edition.

Just for reference, apparently they haven't changed their stance:
http://www.chicagomanualofstyle.org/CMS_FAQ/Pronouns/Pronouns17.html

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120626065804.ge16...@rivendell.home.ouaza.com

Bug#678712: developers-reference: Please make developers reference gender neutral

[Raphael Hertzog]

On Tue, 26 Jun 2012, Charles Plessy wrote:
> before it is too late.  I also would like to add that it is a bit of a 
> slippery
> slope to use "seconded" statements as votes instead of indications that the
> discussion has ended on a conclusion, as it is done with the Policy, where 
> this
> method originates.

FWIW, I applied the patch because I also did my own research some times
ago when I decided of some style guidelines for the Debian Administrator
Handbook (mostly following the Chicago Manual of Style). And I came to the
same conclusion.

And I got similar advice from a friend who's teaching English in France.

> singular they.  I think that therefore it is a matter of choice and the
> important is to be consistent across the document, so please mention somewhere
> what standard the Developers Reference is following.

Added a sentence in README-contrib.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120626064610.gd16...@rivendell.home.ouaza.com

Bug#678712: developers-reference: Please make developers reference gender neutral

[Raphael Hertzog]

Hi,

On Sat, 23 Jun 2012, Steve Langasek wrote:
> Attached is a corrected patch, which fixes the verb agreement issue above
> and makes a few other tweaks (e.g., not introducing passive tense where it's
> not needed, which is worse than the original problem it aims to fix), and
> also catches a few more gender-specific pronouns that were overlooked.

Thank you Steve and Per for this patch. I applied it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120625190053.gb11...@rivendell.home.ouaza.com

Bug#678710: developers-reference: Clarify that removal of package from testing is possible

[Raphael Hertzog]

Hi,

On Sat, 23 Jun 2012, Per Andersson wrote:
> See attached patch for clarification of removals from testing.

Thanks, applied.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120625185447.ga11...@rivendell.home.ouaza.com

Bug#666578: Fixed FTBFS in SVN

[Raphael Hertzog]

Hi,

On Sat, 09 Jun 2012, David Prévot wrote:
> Developpers-reference maintainers, do you want to address any more issue
> before actually uploading the package? If not, I'll poke translators as
> soon as I get an ACK from any of you, or within five days if I don't get
> a NACK.

I have not planned to work on the package any time soon, so feel free to
go ahead from my point of view.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120610124550.gf21...@rivendell.home.ouaza.com

Bug#587279: debian-policy: section 2.2.1 needs some tweaking

[Raphael Hertzog]

On Tue, 13 Mar 2012, Wouter Verhelst wrote:
> No, that's not correct. If a package is already installed but a newever
> version is available, then this will be upgraded if the priority is 1.
> It just won't be selected for installation automatically.
> 
> This is how experimental works: packages in experimental have priority
> 1, so won't be installed automatically; but the will be upgraded if
> needs be.

I'm sorry but Carsten is right. I routinely add the snippet below
precisely because packages installed from experimental are not upgraded
from experimental without it.

Package: *
Pin: release experimental
Pin-Priority: 150

And it's also the reason why APT now supports a "ButAutomaticUpgrades: yes"
field to complement the "NotAutomatic: yes" field. The result is to have a
priority of 100 instead of 1 (backports.debian.org uses it).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120313131031.ga8...@rivendell.home.ouaza.com

Re: Upcoming Policy plans

[Raphael Hertzog]

On Sun, 26 Feb 2012, Russ Allbery wrote:
> Part of the goal of waiting until we were in release freeze was precisely
> so that it was clear that people shouldn't target wheezy with updates for
> this version of Policy.  Maybe we should make that explicit by declining
> to release the new version into the archive until wheezy is released?
> 
> We could relax the freeze of merging new changes once the conversion is
> done, but just not upload a new version.  It's not like Policy uploads
> have been horribly frequent anyway.

Yeah, it certainly would not hurt.

In terms of general workflow for the project, having lots of policy work
done during a freeze is certainly a good thing so that when development
starts again, the new policy is released and we have lots of time to
implement the required changes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120227105936.gb6...@rivendell.home.ouaza.com

Re: Upcoming Policy plans

[Raphael Hertzog]

On Sun, 26 Feb 2012, Russ Allbery wrote:
> This is an attempt to be bold.  We'll see if it actually survives contact
> with reality.  :)

Great, thank you for this!

> Then, my plan is to declare a Policy freeze on May 1st.  Hopefully by that
> point we'll be into release freeze as well.  I then want to take the next
> month (or less if it gets done faster) and convert Policy to DocBook.

I would suggest you to have a look into publican when you're at that
point. You could then look into using "conditionals" to add supplementary
information (like rationale) but leave it out from the standard build.

http://jfearn.fedorapeople.org/en-US/Publican/2.7/html/Users_Guide/chap-Users_Guide-Creating_a_document.html#sect-Users_Guide-Conditional_tagging

> I would prefer not to just do a mechanical conversion, and instead take
> the opportunity to do some substantial cleanup.  If we're going to change
> everything and probably break the anchors for external links, we may as
> well do as much other cleanup as we can get done at the same time.  It's
> been a long time since Policy has been edited as a coherent document, and
> it shows.  It may be that I'll run out of time or energy and we'll make do
> with a more mechanical conversion, but that's the hope.

My only fear is that releasing a policy so late in the cycle will lead to
many uploads partly to get in sync with the latest policy in wheezy. In
particular if you end up releasing it as 4.0.0 as I would expect it.

> I've opened bug #661417 to track any additional cleanups that we want to
> do at the same time.  Simple things that don't require discussion can be
> added directly to that bug.  For more complex things that may require some
> discussion, please open a separate bug and mark it as blocking that bug.

Not sure whether/how you want to record the above suggestion. I'll leave
it up to you.

> What does everyone think about this plan?

It's a good one.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120227074231.gc30...@rivendell.home.ouaza.com

Re: [proposal] remove the requirement to compress documentation

[Raphael Hertzog]

On Tue, 21 Feb 2012, Wouter Verhelst wrote:
> On Mon, Feb 20, 2012 at 07:09:40PM +0100, Wouter Verhelst wrote:
> > On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote:
> > > Debian is used on small systems where users still like to have 
> > > documentation, and
> > > support zlib compression is almost universal.
> > 
> > I would not have any objection against a tool which would compress files
> > upon installation for those users who want it. But I don't think having
> > to compress files inside the .deb package buys us very much anymore.
> 
> To be a bit more specific on this: such a tool could be implemented
> fairly trivially with a dpkg trigger. Just register a trigger that
> triggers on any file under /usr/share/doc, and have it call gzip --best
> on the files it is called with.

This is a common misunderstanding with dpkg's file triggers. When the
trigger is activated, you only know that something changed in
/usr/share/doc but you don't know what changed.  So it would be a rather
costly operation to rescan all of /usr/share/doc/ just to compress the new
files.

Furthermore, just like Russ said, it's a very bad idea to change files
installed by dpkg. If you change the filename, dpkg won't find the file
when it has to remove the package. (Even if you had only to change the
content, you'd break tools like debsums)


That said, I tend to agree that compressing the documentation is a net
loss nowadays. For the cases where space matters, we have either
dpkg --path-exclude, or we have the possibility to use a filesystem
that compresses data transparently (btrfs, zfs, jffs, etc.).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120221080142.gb22...@rivendell.home.ouaza.com

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

[Raphael Hertzog]

On Mon, 30 Jan 2012, Russ Allbery wrote:
> > And you must take care because $(shell dpkg-buildflags ...) will not see
> > the DEB_CFLAGS_MAINT_PREPEND that you have set in the rules
> > files. Either you do $(shell
> > DEB_CFLAGS_MAINT_PREPEND=... dpkg-buildflags ...) or you use
> > /usr/share/dpkg/buildflags.mk which does the right thing for you.
> 
> Or you just use:
> 
> export DEB_CFLAGS_MAINT_PREPEND = -Wall

No because $(shell ...) only gets environment variable that were existing
at the time make has been invoked. Variables exported by the makefile
itself are not forwarded. :-(

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120130201024.ge6...@rivendell.home.ouaza.com

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

[Raphael Hertzog]

On Fri, 27 Jan 2012, Matthijs Kooijman wrote:
> > -ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
> > -CFLAGS += -O0
> > -else
> > -CFLAGS += -O2
> > -endif
> > +CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
> >  ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
> >  INSTALL_PROGRAM += -s
> >  endif
> 
> Wouldn't it be more appropriate to use
> 
> DEB_CFLAGS_MAINT_PREPEND := -Wall
> 
> here before calling dpkg-buildflags? Possibly the rest of the example
> could be modified to use DEB_CFLAGS_MAINT_APPEND as well.

Well, they are there so that you can tweak the output of dpkg-buildflags
when the call happens in lower layer and that you have no control over the
call and its output.

And you must take care because $(shell dpkg-buildflags ...) will not see the
DEB_CFLAGS_MAINT_PREPEND that you have set in the rules files. Either you
do $(shell DEB_CFLAGS_MAINT_PREPEND=... dpkg-buildflags ...) or you use
/usr/share/dpkg/buildflags.mk which does the right thing for you.

> Not sure if this is really needed, but it seems to me that that is what
> these variables were invented for :-)

Maybe all the samples from Policy should be simplified to use the Makefile
snippets...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120130141426.gc20...@rivendell.home.ouaza.com

Bug#657107: developers-reference : styles of handwriting are Bold

[Raphael Hertzog]

On Tue, 24 Jan 2012, Nobuhiro Iwamatsu wrote:
> A.2.2. debdiff,  A.5.3. dcut and A.6.7. dpkg-depcheck styles of
> handwriting are Bold.
> It seems that it will be changed into bold if it surrounds by .
> Commands other than these are surrounded by .
> Therefore, the style of handwriting is not Bold.
> 
> Please see
>   http://www.debian.org/doc/manuals/developers-reference/ .

I'm afraid that the change is semantically wrong... neither debdiff, dcut, nor
dpkg-depcheck are packages. They are commands available in the
devscripts/dput packages.

If you want to fix this inconsistency, I would suggest to standardize on
the command name rather than on the package name (and/or add the package
name when it differs from the command name). But I haven't checked if it's
possible.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120124070812.gg7...@rivendell.home.ouaza.com

Bug#571776: document symbols

[Raphael Hertzog]

On Fri, 13 Jan 2012, Russ Allbery wrote:
> +   
> + 
> +library-soname main-dependency-template
> +[ | alternative-dependency-template ]
> +[ ... ]
> +[ * field-name: field-value ]
> +[ ... ]
> + symbol minimal-version[ 
> id-of-dependency-template ]
> + 

I think this description adapted from the deb-symbols(5) manual page
mislead you into thinking that there were leading spaces before | or *
when in fact there are none.

I have updated the manual page to make it look like this now:

library-soname main-dependency-template
[| alternative-dependency-template]
[...]
[* field-name: field-value]
[...]
 symbol minimal-version [id-of-dependency-template]

> +   
> +libGL.so.1 libgl1
> + | libgl1-mesa-glx #MINVER#

Drop the leading space on that last line.

> + publicGlSymbol@Base 6.3-1
> + [...]
> + implementationSpecificSymbol@Base 6.5.2-7 1
> + [...]

> + For our example, the zlib1g symbols file
> + would contain:
> + 
> + * Build-Depends-Package: zlib1g-dev

And here too.

> + 
> + (Don't forget the space before the * so that it will
> + be parsed as part of the entry for that library.)

And that sentence is then useless (or needs to be reworded).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113195534.ge14...@rivendell.home.ouaza.com

Bug#571776: document symbols

[Raphael Hertzog]

On Fri, 13 Jan 2012, Russ Allbery wrote:
> >>For our example, the zlib1g symbols file
> >>would contain:
> >>
> >>  * Build-Depends-Package: zlib1g-dev
> >>
> >>(Don't forget the leading space.)
> 
> > What leading space are you referring to ?
> 
> I now have:
> 
>   (Don't forget the space before the * so that it will
>   be parsed as part of the entry for that library.)
> 
> Due to the way that the formatting of Policy works, it's very hard to tell
> that there's a space there, and unlike with symbols where the indentation
> is fairly obvious, it's not completely obvious that it's required.

There is no leading space before the "*". Just like "|" it must be
on the first column to differentiate with symbol definitions which do have
a leading space on their lines.

> Thanks for the review!

All the other corrections you made are fine. Thanks!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113193823.gd14...@rivendell.home.ouaza.com

Bug#571776: document symbols

[Raphael Hertzog]

Hi,

On Mon, 02 Jan 2012, Russ Allbery wrote:
>   
> If a package contains a binary or library which links to a
> shared library, we must ensure that, when the package is
> installed on the system, all of the libraries needed are also
> installed.  These dependencies must be added to the binary
> package when it is built, since they may change based on which
> version of a shared library the binary or library was linnked

s/linnked/linked/

[...]
>   
> shlibs files were the original mechanism for
> handling library dependencies.  They are documented
> in .  symbols files,
> documented in this section, are recommended for most packages,
> since they provide dependency information for each exported
> symbol and therefore generate more accurate dependencies for
> binaries that do not use symbols from newer versions of the
> shared library.  However, shlibs files must be used
> for udebs.  Packages which provide a symbols file
> are not required to provide a shlibs file.
>   

In practice I don't think that we have any package providing a symbols
files without a shlibs file.

[...]
 
>   
> How to use dpkg-shlibdeps and the
>   symbols files
> 
> 
>   If your package contains any compiled binaries or shared
>   libraries, put a call to dpkg-shlibdeps into
>   your debian/rules file in the source package.
>   List all of the compiled binaries, libraries, or loadable
>   modules in your package.


>   If your source package builds only a
>   single binary package that contains only compiled binaries and
>   libraries (but no scripts) and is not multiarch, you can use a
>   command such as:
>   
> dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
>   debian/tmp/usr/lib/*
>   
>   but normally finding all of the binaries is more
>   complex.

I would drop the part above (up to the 4 dashes that I added). This
example will only mislead people IMO because debian/tmp/ is far from being
the norm. debian/ is much more common for single binary packages. And
as you said, it doesn't cover all cases.

> 
> The easiest way to do this is to use a package helper
> framework such as debhelper.  If you are
> using debhelper, the dh_shlibdeps
> program will do this work for you.  It will also correctly
> handle multi-binary packages.
>   
> 
> 
> 
>   This command puts the dependency information into
>   the debian/substvars file, which is then used
>   by dpkg-gencontrol.  You will need to place
>   a ${shlibs:Depends} variable in the Depends
>   field in the control file of every binary package built by
>   this source package that contains compiled binaries,
>   libraries, or loadable modules.  If you have multiple binary
>   packages, you will need to call dpkg-shlibdeps on
>   each one which contains compiled libraries or binaries, using
>   the -T option to the dpkg utilities to
>   specify a different substvars file for each
>   binary package.
> Again, dh_shlibdeps
> and dh_gencontrol will handle all of this for
> you if you're using debhelper.
>   

I would indicate in the footnote that dh_shlibdeps/dh_gencontrol use an
alternate substvars file by default (debian/.substvars).

>   
> The symbols File Format
[...]
>   For our example, the zlib1g symbols file
>   would contain:
>   
>  * Build-Depends-Package: zlib1g-dev
>   
>   (Don't forget the leading space.)

What leading space are you referring to ?

[...]
>   
> The shlibs files present on the
>   system
[...]
> 
>   DEBIAN/shlibs files in the "build
> directory"
> 
>   
> When packages are being built,
> any debian/shlibs files are copied into the
> control information file area of the temporary build
> directory and given the name shlibs.  These
> files give details of any shared libraries included in
> the same package.
>   
> 

debian/shlibs is (no longer) a standard file... debhelper doesn't install
such files, it generates shlibs files on the fly and I don't believe that
any modern package still has debian/shlibs.

So I would rewrite this paragraph to just say that DEBIAN/shlibs is the
shlibs file produced by the current package build.

[...]
>   
> Providing a shlibs file
> 
> 
>   If your package provides a shared library, you need to create
>   a shlibs file following the format described

Bug#629530: developers-reference: PDF code example has wrong U+2019 for '

[Raphael Hertzog]

Hi,

On Mon, 09 Jan 2012, David Prévot wrote:
> As you may have noticed, the English document looks different: I quickly
> copied and pasted part of the maint-guide build system (the xslt
> directory is directly copied from there, and probably needs to be
> adapted to keep the current look), in order to build the Japanese PDF:

Why did you have to do this change? Was it not enought to just add
--backend=xetex?

Doesn't that change also change the build dependencies?

> Since the Japanese translation is now complete, it would be nice if we
> could upload the package with the Japanese PDF once properly solved this
> issue (keeping the English document look too). Unless some more stuff
> needs to be addressed regarding the text, can I poke the German
> translator in order to upload an up to date package soon (within ten days)?

Sure.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120110072613.gg31...@rivendell.home.ouaza.com

Bug#628515: recommending verbose build logs

[Raphael Hertzog]

Hi,

On Mon, 28 Nov 2011, Jonathan Nieder wrote:
> On the other hand, if you are saying that packagers should not wait
> for any official pronouncement to implement whatever
> DEB_BUILD_OPTIONS=verbose/quiet option they please, then I would agree
> with you.  xz-utils has supported DEB_BUILD_OPTIONS=quiet for a while
> now.  However, I thought Matthias was looking for something more
> consistent between packages, like making sure that logs are verbose
> when DEB_BUILD_OPTIONS is unset (or making sure that logs are verbose
> when DEB_BUILD_OPTIONS=verbose, whatever.  Either way.)

For reference dpkg supports "DEB_BUILD_OPTIONS=maintainer-build" that
enables the silent rules and I have an alias "dpkgbuild" that avoids
me to have to type this every time.

Maybe a discussion on -devel would be helpful to try to standardize on a
name.

I also think that it would be more convenient to have the buildd set the
verbose mode and others to have the silent rules by default but I don't
think this is going to take traction. We have quite a few bugreports from
users doing rebuilds and it's best to get verbose build logs in those
cases.

That's why I suggest to aim directly for the opposite: verbose by default
and silent with a switch that maintainers can add. Ideally though debuild
would get support for this option and could be taught to set it
via some ~/.devscripts setting.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2028075437.ga14...@rivendell.home.ouaza.com

Bug#637614: §9.10: Do not recommend to call install-docs, as it is triggered.

[Raphael Hertzog]

On Sat, 05 Nov 2011, Bill Allombert wrote:
> On Sat, Aug 13, 2011 at 01:14:31PM +0900, Charles Plessy wrote:
> > Package: debian-policy
> > Version: 3.9.2.0
> > Severity: normal
> > 
> > Dear all,
> > 
> > here is a patch that updates §9.10: now that doc-base uses triggers, I 
> > think it
> > is better to simply recommend to install the control files in
> > /usr/share/doc-base/, instead of recommending the use of install-doc.
> 
> Hello Charles,
> 
> Your proposed change is mostly a statement about dpkg behaviour, so I would 
> like it
> to be seconded by a dpkg developer.

I don't really see what dpkg developers have to do here...

In any case I can confirm that doc-base is installing a trigger to be
notified of changes in /usr/share/doc-base and that its trigger calls
"install-docs --install-changed".

So Charles's request seems reasonable to me. Seconded.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


signature.asc
Description: Digital signature

Bug#647570: debian-policy: Conformance of Chapter 5 to RFC 2119.

[Raphael Hertzog]

On Sat, 05 Nov 2011, Bill Allombert wrote:
> Of course entities are translatable. What are you actually wanting to say ?

Well, nowadays we expect to handle translations just with PO files. And in
this context, you're expected to keep an entity between the original
string and the translated one.

"a package &must; have a version"
"un paquet &must; avoir une version"

This won't work, so the translators would have to use "un paquet DOIT
avoir une version" (i.e. replacing the entity with its translated value).
Or we would have to add entities for all translations... or we would have
to have localized definitions of all entities (likely without using PO
files but some custom mechanism).

None of this is really clean IMO and it's really abusing entities
for a weird goal ("allowing people to generate a version of the policy
without uppercase").

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2005212705.gc25...@rivendell.home.ouaza.com

Bug#647570: debian-policy: Conformance of Chapter 5 to RFC 2119.

[Raphael Hertzog]

On Fri, 04 Nov 2011, Bill Allombert wrote:
> I would suggest we use entities instead of hard-coding 'MUST NOT/SHOULD NOT'.
> This way it will be easier to generate policy document with the lower case
> variant for people who cannot read uppercase words.

Entities are not translatable. Even if there's no current translation of
the policy, I believe we should not use entities for english words
that ought to be translatable.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2004135234.gb17...@rivendell.home.ouaza.com

Bug#643930: Adjust link to Mentor's FAQ

[Raphael Hertzog]

Hi,

On Sat, 01 Oct 2011, Charles Plessy wrote:
> how about also removing ‘unofficial’ in the sentence below ?
> 
>   Please read the unofficial debian-mentors FAQ aturl="&url-mentors;"> first.

Agreed, I have made the change locally, will push later.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111012070639.gd30...@rivendell.home.ouaza.com

Bug#642914: debian-policy: 10.8 Log files : logrotate compression should result from good judgment

[Raphael Hertzog]

On Mon, 26 Sep 2011, Raphael Hertzog wrote:
> "Thinking" is not enough, we would like to see facts.

I just wanted to add that changing this means changing the names of many
compressed log files and potentially breaking some (custom) scripts which
are relying on the current configuration.

So I think we should not impose/change this unless we have a very convincing
argument and I think you have not provided it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110926061612.gh22...@rivendell.home.ouaza.com

Bug#642914: debian-policy: 10.8 Log files : logrotate compression should result from good judgment

[Raphael Hertzog]

Hello Jérôme,

you have been filing such bugs in Ubuntu and I closed at least one you
filed against dpkg.

I hope that if this debian-policy request gets turned off, you will stop
filing such wishlist bugs everywhere.

On Sun, 25 Sep 2011, Jérôme wrote:
> Most of the time I think that log files compression lowers the system
> performance on desktop computers which have now enough disk space for storing
> old logs.

"Thinking" is not enough, we would like to see facts.

There are many cases where there are requirements to keep logs over
multiple years and keeping all those logs uncompressed is a waste of the
disk space.

> The question is not about cpu and memory resources but mostly about energy
> consumption.

1/ Buying a supplementary disk (and thus producing it) consumes probably more
energy than compressing files on the former disk.

2/ It's not clear that you get any significant reduction of energy
consumption. Sure compressing/decompressing takes some CPU, but then
reading on the disk also consumes energy and a smaller file is read
faster.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110926060505.gb22...@rivendell.home.ouaza.com

Bug#641153: document Built-Using field for binary packages

[Raphael Hertzog]

On Sun, 11 Sep 2011, Charles Plessy wrote:
> This adds Built-Using in §5.6.10 (“Package interrelationship fields: Depends,
> Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides, Replaces,
> Enhances”).  In Policy's chapter 5, the fields in that list are documented to
> be present in source package control files (§5.2) and binary package control
> files (§5.3).  However, dpkg-source does not allow the field in source package
> control files (allowed => ALL_PKG, see scripts/Dpkg/Control/Fields.pm).

I don't understand your reasoning... "Depends" is also "allowed =>
ALL_PKG" which means allowed in "control" in the .deb, and in a package
entry in debian/control (and in a Packages file and in
/var/lib/dpkg/status).

On the contrary, internally it's really very close to other dependency
fields... it's treated like a "union"-dependency field (like
Breaks/Conflicts).

> Since the only purpose of this paragraph is to allow to list pipe-separated
> alternatives, I propose to not add Built-Using to that paragraph, as in my
> undersanding it is not expected to list alternatives.

It's not even allowed since it's a "union"-dependency field.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110911063233.gf9...@rivendell.home.ouaza.com

Bug#569219: Document transitional and meta-packages

[Raphael Hertzog]

On Mon, 15 Aug 2011, Luca Falavigna wrote:
> > Right. Could someone update the patch?
> 
> Patch refreshed with Santiago's suggestions.
> I took the time to expand it a little bit.

I merged it but I changed the wording (hopefully improving it!).
Cf attached patch.

Thanks for your contribution!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)
commit bdd25dee4f0faa21895e09141ce962807b8cc4d2
Author: hertzog 
Date:   Tue Sep 6 07:26:22 2011 +

Document some best practices for meta-packages. Extend those for 
transitional packages. Based on a patch by Luca Falavigna 
 (thanks!). Closes: #569219

git-svn-id: 
svn+ssh://svn.debian.org/svn/ddp/manuals/trunk/developers-reference@8921 
313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 4f47a69..8b03c47 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -1670,6 +1670,13 @@ your short description.  If you are looking for 
examples, just run:
 apt-cache search .|grep dummy or
 apt-cache search .|grep transitional.
 
+
+Also, it is recommended to adjust its section to
+oldlibs
+and its priority to
+extra
+in order to ease deborphan's job.
+
 
 
 
@@ -1897,6 +1904,33 @@ debugging symbols for, and this dependency should be 
versioned.  For example:
 Depends: libfoo (= ${binary:Version})
 
 
+
+Best practices for meta-packages
+
+A meta-package is a mostly empty package that makes it easy to install a
+coherent set of packages that can evolve over time. It achieves this by
+depending on all the packages of the set. Thanks to the power of APT, the
+meta-package maintainer can adjust the dependencies and the user's system
+will automatically get the supplementary packages. The dropped packages
+that were automaticaly installed will be also be marked as removal
+candidates (and are even automatically removed by aptitude).
+gnome and
+linux-image-amd64 are two examples
+of meta-packages (built by the source packages
+meta-gnome2 and
+linux-latest)
+
+
+The long description of the meta-package must clearly document its purpose
+so that the user knows what he will lose if he removes the package. Being
+explicit about the consequences is recommended. This is particularly
+important for meta-packages which are installed during initial
+installation and that have not been explicitly installed by the user.
+Those tend to be important to ensure smooth system upgrades and
+the user should be discouraged from uninstalling them to avoid
+potential breakages.
+
+
 
 
 
diff --git a/debian/changelog b/debian/changelog
index 6811e6f..bcc5b6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+developers-reference (3.4.7) UNRELEASED; urgency=low
+
+  * Document some best practices for meta-packages. Extend those for
+transitional packages. Based on a patch by Luca Falavigna
+ (thanks!). Closes: #569219
+
+ -- Raphaël Hertzog   Tue, 06 Sep 2011 09:19:21 +0200
+
 developers-reference (3.4.6) unstable; urgency=low
 
   [ Raphaël Hertzog ]

Bug#639663: [debian-policy] Please provide upgrading-checklist via web

[Raphael Hertzog]

Hi,

On Sat, 03 Sep 2011, Giovanni Mascellani wrote:
> I though about this, but couldn't come up with any easy solution. I
> mostly consider this tool to be useful for people who just have to check
> the very last versions of the policy, so the problem is actually quite
> mitigated.
> 
> I don't even think that old versions of the policy are available online.

Policy could start putting "id" attributes to sections linked from the
upgrading checklist. Then those references will be more stable that plain
section numbers.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110904071314.gn29...@rivendell.home.ouaza.com

Bug#629530: On line developers-reference now extracted from package

[Raphael Hertzog]

On Mon, 04 Jul 2011, David Prévot wrote:
> I can't remember how the branches looks like on DDP Subversion
> repository, and I can't find an on line view of Subversion repository on
> the new Alioth front-end, could someone please refresh my memory or push
> developers-reference r8880 content to its 3.4.5 tag?

You have another alternative, using the command line. :)
$ svn ls svn+ssh://svn.debian.org/svn/ddp/manuals/tags/developers-reference|tail
3.3.3/
3.3.4/
3.3.5/
3.3.6/
3.3.7/
3.3.8/
3.3.9/
3.4.0/
3.4.3/
3.4.4/

Done anyway.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110705060612.ge7...@rivendell.home.ouaza.com

Re: [RFC] Skipping new-prerm failed-upgrade?

[Raphael Hertzog]

Hi,

On Sat, 18 Jun 2011, Jonathan Nieder wrote:
> Raphael Hertzog wrote:
> > 1/ I'd argue that in the case of downgrade, dpkg should not try to run
> >the failed-upgrade fallback because there's no way the oldest version
> >can be aware of how to work-around a problem in a prerm script of a
> >newer version that did not exist at the time the oldest prerm was
> >written.
> >
> >Suggested patch attached. Do you agree with this? Do you see possible
> >problems with this?
> 
> The patch doesn't seem to be attached, but that makes perfect sense to
> me.  If the new prerm is failing for no good reason, a person can upgrade
> to a version with the bug fixed and then downgrade.

Oops, sorry, it's here:
http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=4bf0cb997ee46563fae8d43424c8bd6fe6cd21cb

> 
> > 2/ It would be nice to have a way for the prerm script to explicitly
> >disable the fallback. Maybe we could define a special exit code that
> >the "prerm upgrade" can use to tell dpkg to not consider the fallback.
> 
> That would defeat the point of having a fallback (namely avoiding bugs
> putting systems into a state with no automatic way in the packaging
> system to get out of it), so I think it's an awful idea. ;-)  If you
> can't trust the maintainers of future versions of your package, who
> can you trust?

Yeah, good point. And for upgrade it's the preinst that matters more, i.e.
for example when udev doesn't want to be upgraded because the kernel is
too old. And there there's no similar problem of fallback.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110619183850.gf20...@rivendell.home.ouaza.com

[RFC] Skipping new-prerm failed-upgrade?

[Raphael Hertzog]

Hi,

to better understand this mail you can refer to this diagram
http://people.debian.org/~srivasta/MaintainerScripts.html#sec-3.4.3

During an upgrade from V1 to V2, if "V1->prerm upgrade V2" fails, dpkg tries
to run "V2->prerm failed-upgrade V1" and if it works the upgrade
continues normally.

This is very practical if V1 had a bug in its prerm script, it can be
worked around with some specific code in V2 and let the upgrade continue

Now there are cases where we really want to stop the upgrade from the
prerm. We have the case with dpkg where don't want to allow a downgrade
if we have packages that rely on a dpkg feature that the target version
does not support. For now it works because we did not have any prerm
in the old versions but as soon as you have a prerm you're screwed because
in general the scripts always "exit 0" for the failed-upgrade case.


I would thus like to discuss 2 ideas:

1/ I'd argue that in the case of downgrade, dpkg should not try to run
   the failed-upgrade fallback because there's no way the oldest version
   can be aware of how to work-around a problem in a prerm script of a
   newer version that did not exist at the time the oldest prerm was
   written.

   Suggested patch attached. Do you agree with this? Do you see possible
   problems with this?

2/ It would be nice to have a way for the prerm script to explicitly
   disable the fallback. Maybe we could define a special exit code that
   the "prerm upgrade" can use to tell dpkg to not consider the fallback.

   Or do you see another way for the script to indicate this to dpkg?

   If the exit code approach makes sense, what exit code could we use for
   this?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110618194847.gb11...@rivendell.home.ouaza.com

Re: Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[Raphael Hertzog]

Hi,

On Thu, 16 Jun 2011, chris h wrote:
> We (Grml) would like to switch back to short Version: strings for our
> kernel packages, as they already have the major "version number" in
> the package name, to allow co-installation of multiple versions, and
> there's no point in duplicating this info in the Version field.
> (Making the Version field relatively long and unreadable.)

"0" is very short. If you don't need the version at all, you don't need to
put a text string either.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110616092341.ga13...@rivendell.home.ouaza.com

Bug#629530: developers-reference: PDF code example has wrong U+2019 for '

[Raphael Hertzog]

Hi David,

On Wed, 08 Jun 2011, David Prévot wrote:
> Lucas, Raphaël, could we consider moving away of pdflatex build? This
> may allow to build the Japanese PDF, which would also be an improvement.

I don't care much of the build process (as long as it works and it stays
out of my way).

If anything, I would be interested to use publican as it has native
support for i18n via PO files and generates good looking documents
without much work. It doesn't use TeX for its PDF output but fop.

> If we are going that road, since some packages may not be available in
> Lenny still used on www-master to build the developers-reference, it
> could be a good time to extract the content from the latest package than
> building the Subversion version on www-master.

No opposition from me.

> If you agree on that (even if you don't actually ;-), maybe could it be
> a good time to upload the latest version of the developers-reference
> which add a new translation. I'll ask for translation update if they're
> not up to date in order to do so, unless you disagree.

Do you have upload rights? If yes, feel free to to the upload yourself
(mark it as "Team upload" to avoid the lintian warning and you're done).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110609122333.gd12...@rivendell.home.ouaza.com

Bug#604397: debian-policy: require build-arch and build-indep targets

[Raphael Hertzog]

Hi,

On Mon, 06 Jun 2011, Guillem Jover wrote:
> And to me that's one of the problems with Build-Options/Features,
> another being the duplicated information. If we consider
> build-arch/build-indep something useful enough to be widely usable
> on all packages producing arch:any + arch:all packages, then making
> this optional is close to keeping status quo, I expect a multi-year
> period to make a dent on packages adding support for this, if at all.

That's true but so is it for any new feature unfortunately. And even with
a flag day, once you have fixed the FTBFS, you're far from having benefits
from that separation. Because most of the packages that do not FTBFS are
still not converted to make usage of it. They would still run the same
build process in both cases.

> If this is considered only useful to a handful of packages, then
> really, what's the point of all the discussions? All that energy
> could have been used in NMUs instead.

How so? If dpkg-buildpackage only calls "build" I don't see what you could
have NMUed.

Except turning build into an empty target and adding
build-arch/build-indep as dependencies of binary-arch/binary-indep
but that would not be nice since it means compilation is run
as root when it's usually not.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110606191541.ga...@rivendell.home.ouaza.com

Bug#604397: Request for TC to rule on a course of action for supporting build-arch

[Raphael Hertzog]

Hi,

On Mon, 06 Jun 2011, Roger Leigh wrote:
> Has the following been considered:
> - adding a command-line option for dpkg-buildpackage to explicitly
>   enable particular build-features (overriding the feature in the
>   source package).

This has not been suggested yet, I'm not opposed to the idea and would
probably merge a patch for it.

> The question to consider here is whether or not this particular build
> feature is "transitional" or if it will remain indefinitely.

That really depends on the outcome of the policy process and/or the
tech-ctte decision.

I'm not opposed to anything although I do believe that the split
between build-arch and build-indep is only useful for a minority of
packages.

> We don't currently have an option to build /only/ binary-indep
> packages, but this might be useful for arch-all autobuilding if we
> don't want to build them at the same time as for binary-arch.
> In this case, would we still want to install Build-Depends and
> Build-Depends-Indep?  (I would think so.)

Yes, Build-Depends is required for the clean target.

> We don't currently have a Build-Depends-Arch and Build-Conflicts-Arch;
> but this might be useful.  This would allow Build-Depends to be used
> for "generic" dependencies required for both build-arch and
> build-indep, e.g. debhelper, cdbs etc.  And it would mean that when
> doing a binary-indep-only build, the buildd won't need to install
> masses of -dev packages which won't be used, since they would be in
> Build-Depends-Arch.

I don't think that we need to optimize the build process for the
arch-all buildd.

It's not a big deal if we install too many packages... the added
complexity on the other hand is worrying. But it would probably be cleaner
and maybe clearer (the lack of symetry between Build-Depends and
Build-Depends-Indep has confused many people).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011060615.ga...@rivendell.home.ouaza.com

Re: Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[Raphael Hertzog]

Hi,

On Tue, 24 May 2011, Bill Allombert wrote:
> 2) This change breaks actual packages. Even if no such package exist in 
> squeeze, users
> could still want to install older or unofficial packages, or created with 
> dpkg-repack.

The next version of dpkg has --force-bad-version to work around this.

I'm not sure it's highly constructive to ask Guillem to revert the change
at this point since the impact on Debian is very low and a way has been
provided to install packages with bad versions.

Please reconsider. I think it's been well explained that version numbers
ought to start with a "number".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110524210855.ga28...@rivendell.home.ouaza.com

Bug#626779: debian-policy: Improve Architecture field in source package (updated to match dpkg-source)

[Raphael Hertzog]

Hi,

On Mon, 16 May 2011, Guillem Jover wrote:
> > +The list may include (or consist solely of) the special
> 
> This has switched from tabs to spaces.

This is due to a bad "vim" modeline. I fixed it as well. Looks like policy
editors mainly use emacs :)

> With those fixed, seconded.

Updated patch attached.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)
diff --git a/policy.sgml b/policy.sgml
index 9b4a93e..0650306 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2975,10 +2975,14 @@ Package: libc6
 
  
In the source package control file .dsc, this
-   field may contain either the architecture
-   wildcard any or a list of architectures and
-   architecture wildcards separated by spaces. If a list is
-   given, it may include (or consist solely of) the special
+   field contains a list of architectures and architecture
+   wildcards separated by spaces. When the list contains the
+   architecture wildcard any, the only other value
+   allowed in the list is all.
+ 
+
+ 
+   The list may include (or consist solely of) the special
value all.  In other words, in .dsc
files unlike the debian/control, all may
occur in combination with specific architectures.
@@ -2989,19 +2993,23 @@ Package: libc6
  
 
  
-   Specifying any indicates that the source package
+   Specifying only any indicates that the source package
isn't dependent on any particular architecture and should
compile fine on any one. The produced binary package(s)
-   will either be specific to whatever the current build
-   architecture is or will be architecture-independent.
+   will be specific to whatever the current build architecture is.
  
 
  
Specifying only all indicates that the source package
-   will only build architecture-independent packages.  If this is
-   the case, all must be used rather than any;
-   any implies that the source package will build at
-   least one architecture-dependent package.
+   will only build architecture-independent packages.
+ 
+
+ 
+   Specifying any all indicates that the source package
+   isn't dependent on any particular architecture. The set of
+   produced binary packages will include at least one
+   architecture-dependant package and one architecture-independent
+   package.
  
 
  
@@ -11272,4 +11280,4 @@ END-INFO-DIR-ENTRY
 
 
 
-
+

Bug#623707: Outdated section on l10n

[Raphael Hertzog]

Hello,

On Fri, 22 Apr 2011, Martin Eberhard Schauer wrote:
> reviewing the German translation I found that this section is
> outdated. I rewrote some
> of the stuff with my background as Debian translator.

Can you send your suggestions as a patch to the docbook files?

$ svn co svn://svn.debian.org/ddp/manuals/trunk/developers-reference
$ cd developers-reference
$ sensible-editor l10n.dbk
$ svn diff >/tmp/patch

And send the /tmp/patch file to this bug report.

Thanks.
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110422140909.ga11...@rivendell.home.ouaza.com

Bug#623512: developers-reference: Patch fixes some typos

[Raphael Hertzog]

On Wed, 20 Apr 2011, Chris Leick wrote:
> Hi,
> 
> while translating this reference to german, I've found some typos
> and punctuation errors. The patch attached will fix them.

No it will not. You need to fix the errors in the .dbk files.

But it's nice to avoid fuzzying the translations, so it's best if you
also fix the errors in the .po/.pot files (of all existing translations).

Can you update your patch?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110421061240.gi22...@rivendell.home.ouaza.com

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[Raphael Hertzog]

On Fri, 08 Apr 2011, Goswin von Brederlow wrote:
> It does not allow them in available though breaking many systems that
> have or in the past had a package with such a version available. At
> least 4 people on irc have run into that problem that I saw already.

It does allow them in available. Those people are confused
or affected by something else.

They might not know how to get rid of the warnings though (dpkg
--clear-avail).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110408183316.ga10...@rivendell.home.ouaza.com

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[Raphael Hertzog]

On Mon, 04 Apr 2011, Carsten Hey wrote:
> upstream_version git1234 could be prefixed with epoch 0 and thus lead to
> the version number 0:git1234-debian_revision.  Maybe this could be
> mentioned in the policy.

No, the check is on the first digit of the "upstream version". The epoch
is ignored.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110404122801.gf25...@rivendell.home.ouaza.com

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[Raphael Hertzog]

Hi,

On Mon, 04 Apr 2011, Bill Allombert wrote:
> > 1. upstream_version must start with a digit;
> 
> Unfortunately, we cannot force upstream to use a version that start by a 
> digit,
> We would need to document a mangling process for upstream version that start
> by a letter.

We have no upstream with such versions currently in Debian. I don't really
see the point of your objection. There's no supplementary work involved in
Debian.

I doubt we'll ever have to mangle the version name to satisfy the
constraint but even if we have to, it's trivial to add a leading 0.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110404121326.gd25...@rivendell.home.ouaza.com

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[Raphael Hertzog]

On Sun, 03 Apr 2011, Russ Allbery wrote:
> My inclination is to second this, but I want to make sure that we've
> answered your and Julien's objections first.

And for complete reference, dpkg accepts those version in
/var/lib/dpkg/status (so that dpkg still works for users with affected
packages installed) but will not a accept to install a .deb with a bad
version anymore.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110404065426.gj21...@rivendell.home.ouaza.com

Bug#89038: mime policy copying update-mime(8)

[Raphael Hertzog]

On Sun, 03 Apr 2011, Russ Allbery wrote:
> The bug:
> 
> http://bugs.debian.org/89038
> 
> is still looking for two more seconds.  This would allow us to retire the
> tiny separate mime-policy document.  Could other folks take a look and
> confirm that all looks well?

Seconded. It's fine for me.

(Note that I pinged the mime-support maintainer which looks like MIA since
he has not yet switched to using triggers support while Emilio Pozuelo
submitted a patch some time ago. If that gets merged, the policy will have
to be updated again.)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110404064232.gi21...@rivendell.home.ouaza.com

Re: 8bit characters in files in Debian packages

[Raphael Hertzog]

On Thu, 31 Mar 2011, Bill Allombert wrote:
> First this might force users to use UTF-8 locale. While this is the default, 
> this is not
> mandatory in Debian. I know users that stays with ISO8859-1 because they have 
> a lot of
> text files in that encoding.
> 
> Until the C.UTF-8 proposal is implemented and mandated, a valid UTF-8 locale 
> might not even
> exist on the system.
> 
> Secondly, filenames inside .deb are not localizable, and it might prove
> problematic for users to deal with filenames in complex encoding. Case
> at end, I do not have Japanese font installed so I could not tell apart
> two filenames.

It's definitely problematic to deal with filenames using another encoding
than the currently configured one. But you don't have to deal "manually"
with non-ascii filenames provided by packages that often.

Filenames are not localizables like any gettext string, but there are
valid use cases where filenames might rightfully contain non-ascii
characters. How would you deal with a software where upstream has made a
choice implying some non-ASCII files if you were to forbid it in Debian
policy ?

The logical conclusion is that we should recommend to avoid non-ASCII
filenames but if it can't be avoided, then they should really be UTF-8
encoded so that it works nicely for the vast majority of users who
stick to the default configuration.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110401070249.gf29...@rivendell.home.ouaza.com

Re: 8bit characters in files in Debian packages

[Raphael Hertzog]

On Thu, 31 Mar 2011, Bill Allombert wrote:
> So this raises two issues:
> 1) should non-7bit characters in filenames be allowed

Yes, I don't see a good reason to forbid them. In particular when we are
in an international environment and we are targetting full localization.

> 2) if yes whould we require the filename to be in a correct UTF-8 encoding ?

I think it would be good, yes. We have standardized on UTF-8 for almost
everything and we should do the same for filenames.

Is there no lintian check covering this?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110331170510.gb27...@rivendell.home.ouaza.com

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

[Raphael Hertzog]

On Wed, 30 Mar 2011, Jonathan Nieder wrote:
> I like your proposed alternative.  Maybe the policy could say that you
> "should" (in the policy sense) thoroughly analyze the consequences and
> alternatives before adding pre-depends, and that one way to do so (in
> a friendly advice sense) is to ask on debian-devel?

Yes.

On Wed, 30 Mar 2011, Jonathan Nieder wrote:
> So, new proposal.  Before adding new Pre-Depends,
> 
>  A. there should be a discussion on debian-devel or debian-release,
> to get eyeballs on the change and spot problems and easier
> alternatives;

Drop debian-release, it's not a general discussion list.

>  B. debian-devel or debian-devel-announce should be at least notified,
> so other Debian developers can factor it into any plans they have
> for changing their own package relationships.

I don't think debian-devel-announce is warranted.

> In particular, this proposal would drop the requirement of consensus.
> Package maintainers generally know what's best; if not, there are
> other ways to deal with that (e.g., convincing them, or referring the
> issue to the ctte if the maintainer is beyond convincing).

Agreed.

In general I'm okay with reformulating section 3.5 to make it more obvious
why the review on -devel is a good idea.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110331060311.gc6...@rivendell.home.ouaza.com

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

[Raphael Hertzog]

On Wed, 30 Mar 2011, Jonathan Nieder wrote:
> Well, I want to interpret it as meaning *something* --- though I'm not
> filing RC bugs or anything.  I had thought that the general rule is
> that violating a policy "should" is always a bug (either in your
> package or in policy), though not necessarily an important one.

When it's a technical rule true, here it's a matter of process. The reason
we request peer review of Pre-Depends is that they have a cost and should
not be abused.

So when you want to add a Pre-Depends, you come to -devel and you say "I
want to add this pre-depends because of X to achieve Y".

Maybe someone else will respond "you can achieve Y by doing Z instead" in
which case you should generally go for the solution Z because you can
avoid the cost of the pre-dependency.

But if nobody comes up with another solution to your problem, then by all
means go ahead with the Pre-Depends... if it causes upgrade problems, the
discussion might come back later but that's part of the way we work.
But the maintainer is still the one who gets to decide what's done in his
own package.


In the precise case of multi-arch, the pre-dependency has already been
discussed as being preferrable over any alternative solution. They have a
higher cost due to stronger dependencies in all packages with binaries
whereas this solution only requires multiarchified libraries to carry the
pre-dependency.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330202600.ga6...@rivendell.home.ouaza.com

Bug#619990: developers-reference: Update of merkel.d.o URLs

[Raphael Hertzog]

tag 619990 pending
thanks

On Wed, 30 Mar 2011, Charles Plessy wrote:
> > Please drop this link. It's really of no use to point people to
> > britney's code (note it's not the web version of the above link...).
> 
> Et voilà ! (attached).

Thanks, applied.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330135433.ga4...@rivendell.home.ouaza.com

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

[Raphael Hertzog]

On Wed, 30 Mar 2011, Jonathan Nieder wrote:
> Package: debian-policy
> Version: 3.9.1.0
> 
> Raphael Hertzog wrote[1]:
> 
> > It has been discussed on -release, not on -devel:
> > http://lists.debian.org/debian-release/2011/02/threads.html#00381
> >
> > (I don't think it matters much given that all important stakeholders where
> > involved)
> 
> No strong objection from me.  I guess that suggests we should change
> policy §3.5 at the same time (to permit discussion of Pre-Depends on
> debian-release as an alternative to debian-devel, for example)?

I don't think so. The reason the discussion started on debian-release was
because the initial solution involved a dependency bump on libc6 (and
would affect migrability of packages). Using the Pre-Depends on the
multiarch-support package was later identified as an elegant solution to
avoid this.

That's why it was discussed there. Otherwise it might well be the case
that it would have been discussed on -devel.

BTW, that section say "should not" and not "must not"... you must allow
some flexibility in the interpretation of the sentence. You seem to be
very keen of interpreting it as a hard rule.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330120315.gb2...@rivendell.home.ouaza.com

Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions

[Raphael Hertzog]

On Tue, 29 Mar 2011, Jonathan Nieder wrote:
> Also I suppose some discussion on debian-devel has already taken place
> to make this pre-dependency possible without worrying about policy
> §3.5?  If not, I'd be interested in either an explicit exception or
> the perfunctory discussion on -devel, whichever is easier.

It has been discussed on -release, not on -devel:
http://lists.debian.org/debian-release/2011/02/threads.html#00381

(I don't think it matters much given that all important stakeholders where
involved)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330062556.ge20...@rivendell.home.ouaza.com

Bug#619990: developers-reference: Update of merkel.d.o URLs

[Raphael Hertzog]

On Wed, 30 Mar 2011, Charles Plessy wrote:
> Hi Raphaël,
> 
> it seems that things changed overnight:

Yes, see 20110329215524.ga21...@thrall.0x539.de by Phil Kern.

> The links to the Git repositories would be an interesting addition.  But I 
> even
> found a third one:
> 
>   http://git.debian.org/?p=tools-release/britney.git
> 
> If there is interest, I can extend the patch to include references to Git
> repositories, but since I am not familiar with them, I would need guidance.

I don't think dev-ref is the place to document the Git repositories in use
by the release team, http://wiki.debian.org/Teams/ReleaseTeam would be
much more suited.

>  If you want to see more details, you can look it up on
> -merkel:/org/&ftp-debian-org;/testing/update_out/ (or
> -in merkel:~aba/testing/update_out to see a setup with
> -a smaller packages file).  Via web, it's at  +ries:/srv/release.debian.org/www/britney/update_output/.

Please use the web URL (http://&ftp-master-host;/testing/update_out/),
it's much more stable & convenient than this path on a Debian machine.

> +Via web, it's at   url="http://&ftp-master-host;/testing/update_out_code/";>.

Please drop this link. It's really of no use to point people to
britney's code (note it's not the web version of the above link...).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330055539.gb20...@rivendell.home.ouaza.com

Bug#619990: developers-reference: Update of merkel.d.o URLs

[Raphael Hertzog]

Hi,

On Tue, 29 Mar 2011, Charles Plessy wrote:
>  - For Britney, I do not find the equivalent on ries.d.o for the following:
>merkel:/org/&ftp-debian-org;/testing/update_out/
>merkel:~aba/testing/update_out  Was it moved somewhere else ?

It's now part of release.debian.org and thus not mirrored
on ries.debian.org.

hertzog@ries:~$ ls -al /srv/ftp.debian.org/web/testing
lrwxrwxrwx 1 dak ftpteam 35  3 juil.  2010 /srv/ftp.debian.org/web/testing -> 
/srv/release.debian.org/www/britney
hertzog@ries:~$ ls -al /srv/release.debian.org/www/britney
ls: cannot access /srv/release.debian.org/www/britney: No such file or directory

But I think it's not very important:
- the former is web accessible at 
http://ftp-master.debian.org/testing/update_output/
- the latter is probably not really the reference implementation of britney 
anymore
  it can either be removed or replaced with 
  http://git.debian.org/?p=debian-release/britney1.git;a=summary and
  http://git.debian.org/?p=debian-release/britney2.git;a=summary

> Index: pkgs.dbk
> ===
> --- pkgs.dbk  (révision 8598)
> +++ pkgs.dbk  (copie de travail)
> @@ -2596,10 +2596,7 @@
>  before or after this main run, depending on the exact type.
>  
>  
> -If you want to see more details, you can look it up on
> -merkel:/org/&ftp-debian-org;/testing/update_out/ (or
> -in merkel:~aba/testing/update_out to see a setup with
> -a smaller packages file).  Via web, it's at  +If you want to see more details, you can look it up on   url="http://&ftp-master-host;/testing/update_out_code/";>.
>  
>  

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110329070955.ga14...@rivendell.home.ouaza.com

Re: New field Package-List in .dsc

[Raphael Hertzog]

On Sat, 26 Mar 2011, Bastian Blank wrote:
> On Thu, Mar 24, 2011 at 04:25:46PM +0100, Raphael Hertzog wrote:
> >First line is always
> > the source entry.
> 
> Do you want this constraint part of the definition or a implementation
> detail?

I don't really care. I think it's cleaner to always have it first but
I don't think it matters much.

On Sat, 26 Mar 2011, Bastian Blank wrote:
> On Sat, Mar 26, 2011 at 09:52:38AM +0100, Raphael Hertzog wrote:
> > But apparently the wanna-build team would like to have this information as
> > well (to know which source packages build arch: all packages). So I'm
> > going to add it and I'll follow you advice of replacing spaces by
> > commas. That way we still have the possibility to add supplementary
> > columns in the future if needed.
> 
> On second thought, I think it is time to make this a key-value list
> instead of bare values. Then we can add or remove values without
> disrupting other users of the infos. Also a vendor may explicitely add
> new values if they think they need it.

That would be overkill. Vendor already have the option to add
supplementary fields[1] so I don't see whey they would have to also be able
add values in that field in particular.

Cheers,

[1] And Ubuntu uses it for Launchpad-Bugs-Fixed in .changes.
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110326134520.gb2...@rivendell.home.ouaza.com

Re: Bug#619131: New field Package-List in .dsc

[Raphael Hertzog]

On Thu, 24 Mar 2011, Russ Allbery wrote:
> The missing architecture was my immediate thought as well, since for a
> moment I thought ftp-master might need it, but then I realized that the
> override settings are arch: all.  So I'm ambivalent.

But apparently the wanna-build team would like to have this information as
well (to know which source packages build arch: all packages). So I'm
going to add it and I'll follow you advice of replacing spaces by
commas. That way we still have the possibility to add supplementary
columns in the future if needed.

On Fri, 25 Mar 2011, Bastian Blank wrote:
> On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote:
> > It looks like this:
> > Package-List: 
> >  src:dpkg admin required
> 
> Is there a reason for not listing the type explicit for every entry?
> Something like this:
>  dpkg source admin required
>  dpkg deb admin required
>  dselect udeb admin optional

No, there was none. I also find this clearer and more scriptable. So
adopted. Thanks.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110326085238.ga32...@rivendell.home.ouaza.com

Re: New field Package-List in .dsc

[Raphael Hertzog]

On Thu, 24 Mar 2011, Julien Cristau wrote:
> Does XC-Package-Type also work?  debhelper uses
> /^(?:X[BC]*-)?Package-Type:\s*(.*)/ to populate the package type.

Yes. I was simplifying somewhat.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324175349.gc6...@rivendell.home.ouaza.com

Re: New field Package-List in .dsc

[Raphael Hertzog]

On Thu, 24 Mar 2011, Bill Allombert wrote:
> On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote:
> > Package-List: 
> >  src:dpkg admin required
> >  dpkg admin required
> >  dpkg-dev utils optional
> >  libdpkg-dev libdevel optional
> >  libdpkg-perl perl optional
> >  udeb:dselect admin optional
> 
> How is the list computed ?

Scanning debian/control and outputting values found in each sections, with
proper fallbacks to the first section (the source section) for binary
packages that do not have Section/Priority fields. First line is always
the source entry.

If the source section does not have Section/Priority fields, then the
value "unknown" is used.

The udeb prefix is added if Package-Type: udeb is set.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324152546.gc19...@rivendell.home.ouaza.com