Re: Bug#299007: Transitioning perms of /usr/local

[Don Armstrong]

On Sun, 14 Jan 2018, Santiago Vila wrote:
> The "/usr/local" directory itself and all the subdirectories created
> by the package should have permissions 755 and be owned by "root:root"
> if /etc/staff-group-for-usr-local does not exist, and they should have
> permissions 2775 (group-writable and set-group-id) and be owned by
> "root:staff" if /etc/staff-group-for-usr-local does exist.

Thanks for doing this work! The original wording took me a few readings
to parse; I suggest this instead:

If /etc/staff-group-for-usr-local does not exist, /usr/local and all
subdirectories created by packages should have permissions 0755 and be
owned by "root:root". If /etc/staff-group-for-usr-local exists,
/usr/local and subdirectories should have permissions 2775
(group-writable and set-group-id) and be owned by "root:staff".

-- 
Don Armstrong  https://www.donarmstrong.com

Q: What Can a Thoughtful Man Hope for Mankind on Earth, Given the
Experience of the Past Million Years?
A: Nothing.
 -- Bokonon _The Fourteenth Book of Bokonon_ (Vonnegut _Cats Cradle_)

Re: Bug#883966: debian-policy: please add MIT/Expat to common licenses

[Don Armstrong]

On Tue, 12 Dec 2017, Russ Allbery wrote:
> Markus Koschany <a...@debian.org> writes:
> > We always distribute the source code along with the binary packages.
> 
> This isn't true: we produce install media that contains only the
> binary packages and not the source.

While we do generate install binary-only install media, we also provide
equivalent access to the corresponding source.

For people distributing our install media without providing equivalent
source, this is a problem; that's why I usually distributed the
binary+source install media instead.[1] (Which apparently aren't made
for 9.0, so I'll just have to have a stack of source CDs again.)

1: 
https://cdimage.debian.org/cdimage/archive/8.8.0/multi-arch/jigdo-dvd/debian-8.8.0-i386-amd64-source-DVD-1.jigdo

-- 
Don Armstrong  https://www.donarmstrong.com

-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
 -- e.e. cummings "XXXIX" _1 x 1_

Bug#844431: Revised patch: Oppose

[Don Armstrong]

On Wed, 16 Aug 2017, Bill Allombert wrote:
> But as a technical document, it is lacking practical recommendation
> for maintainers how to make sure their package build reproducibly

The practical recommendations for maintainers are encoded separately, as
they're evolving. See https://wiki.debian.org/ReproducibleBuilds/Howto
for example.

> and create confusion on the goal by using the term 'reproducible
> build' when 'robust build' is meant (which is a worthwile goal by
> itself, but a different project nevertheless).

I'm not convinced that this change will reduce confusion, as the
reproducible build project has been using this language in Debian for
many years now.

But I could be wrong. Please propose an alternative patch to policy
which addresses your concerns if you feel strongly about it.

-- 
Don Armstrong  https://www.donarmstrong.com

Maybe I did steal your heart
and I am such a perfect criminal
that you never noticed
 -- a softer world #481
http://www.asofterworld.com/index.php?id=481

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> And in the other direction what you describe would leave no way for a
> person to make it visible that he has left the team.

It is rarely my experience that people leave teams in clean, definitive
breaks. If they did, packages wouldn't have to be orphaned by the QA
group. Maintainers would take care of that themselves.

> There is no Intent-To-Orphan bug.

Not currently, but one can be created.

> In a more general note, I am a bit puzzled that it is so controversial
> that machine-readable team membership information is important and
> should continue to be available.

Because maintaining such a field increases the burden on teams for
little to no benefit. I know I haven't bothered to be sure that the
Uploaders field in any of my packages only contains people who are
currently actively involved in maintaining that particular packages.

On Fri, 04 Aug 2017, Bill Allombert wrote:
> Nowadays orphaning is done by reuploading the package with the
> maintainer set to the QA group rather than using a O: wnpp bug.

Good point.

-- 
Don Armstrong  https://www.donarmstrong.com

The smallest quantity of bread that can be sliced and toasted has yet
to be experimentally determined. In the quantum limit we must
necessarily encounter fundamental toast particles which the author
will unflinchingly designate here as "croutons".
 -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability.
AIR 1:3, June, 1995.

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> And it would not work when the latest maintainer upload was by a team
> member who retired or was declared MIA earlier.

That can be found out by recursing until you find a non-MIA individual
who has uploaded since the previous stable release, or something like
that.

> Uploaders is not the only option for doing that, but any change should
> include provising more reliable information - not less reliable
> information.

In practice, Uploaders often only includes people who have ever uploaded
the package, not everyone who is on (or still on) the team. I you'll
have better luck with a who-uploads equivalent.

> An O: bug means that it is confirmed that the package is orphaned, and
> gives permission to everyone to adopt the package immediately.

So just file an an Intent-To-Orphan bug. [This why I suggested to file
the bug against the package, and not against wnpp.]

In N days, the bug can be filed against 

-- 
Don Armstrong  https://www.donarmstrong.com

The terrorist's job is to terrorize the people, to interfere with
freedom in such a way that disrupts ordinary life and commerce. With
due respect, it is clear that the above referenced governmental
agencies are aiding the terrorists' objective.
 -- Gary Fielder in Gary Fielder vs Janet Napolitano et al.

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.
>
> Think of it as a 3 step process:

[...]

> 3. for every package where the maintainer is in Maintainer or Uploaders
>the MIA team either orphans the package, or informs team or 
>co-maintainers through an "Updating the  Uploaders list" bug.

[...]

> The part where removing the Uploaders: requirement could cause 
> regressions is step 3.
> 
> Give for a person a complete list of all packages where this person
> was active" - if we regress on this, it means that packages will
> continue to bitrot in cases where they can currently be orphaned.

MIA could find #3 by looking for all packages where the maintainer is
the most recent uploader, and no other individual has recently uploaded
the package. This would work even if Uploaders: lists people who are not
MIA but have stopped being involved in the team.

If there was any question, filing an O: bug against the package and
marking it affects wnpp should notify the team who can close the O: bug
if the package is still being maintained.


-- 
Don Armstrong  https://www.donarmstrong.com

With one simple pill
we cured unhappiness
and art
 -- a softer world #437
http://www.asofterworld.com/index.php?id=437

Re: Virtual Package names

[Don Armstrong]

On Fri, 10 Mar 2017, Rene HEGEWALD wrote:
> is it possbile to create an inoffical Name for my use, not for
> official use ?

Yep. Debian itself uses a host of packages for installing packages on
its hosts which start with debian.org- something.

See some examples here:

https://anonscm.debian.org/gitweb/?p=mirror/debian.org.git

-- 
Don Armstrong  https://www.donarmstrong.com

nothing except the impossible shall occur
 -- e.e. cummings "XLII" _1 x 1_

Bug#850289: debian-policy: Patch so that there is an Example section in manual pages

[Don Armstrong]

On Thu, 05 Jan 2017, shirish शिरीष wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 06d094c..a55c4ea 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5777,7 +5777,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>  
>   
> Every time the shared library ABI changes in a way that may
> -   break binaries linked against older versions of the shared
> +q  break binaries linked against older versions of the shared
> library, the SONAME of the library and the
> corresponding name for the binary package containing the runtime
> shared library should change.  Normally, this means

You probably already noticed this, but you seem to have an extraneous
'q' there.


-- 
Don Armstrong  https://www.donarmstrong.com

"Them as can do has to do for them as can't. And someone has to speak
up for them as have no voices."
 -- Grandma Aching in _The Wee Free Men_ by Terry Pratchett p227

Bug#806161: Implementing #741573 in policy via NMU

[Don Armstrong]

On February 3, 2016 5:38:31 PM CST, Bill Allombert  wrote:
>I understand you expected more of it but I had to release Policy
>3.9.7.0
>out of schedule to fix a RC bug #812663.
>
>Please let it propagate to testing.


My plan is to upload to delayed, so that should be no problem.
-- 
This is not a signature.

Bug#806161: Implementing #741573 in policy via NMU

[Don Armstrong]

Attached, please find a diff for the NMU which I will upload to resolve
#806161 and implement #741573 in policy in the next few days.


-- 
Don Armstrong  http://www.donarmstrong.com


diff --git a/debian/changelog b/debian/changelog
index c87bc78..5a501d5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+debian-policy (3.9.8.0) unstable; urgency=medium
+
+  * Policy: The Debian menu is optionally supported.
+Wording: Charles Plessy <ple...@debian.org>
+Seconded: Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com>
+Seconded: Cyril Brulebois <k...@debian.org> (for the menu entries)
+Seconded: Russ Allbery <r...@debian.org>
+    Closes: #707851
+
+ -- Don Armstrong <d...@debian.org>  Mon, 01 Feb 2016 20:26:05 -0800
+
 debian-policy (3.9.7.0) unstable; urgency=low
 
   * Policy: refreshed the names of the Policy Editors.
diff --git a/policy.sgml b/policy.sgml
index 404dc73..ee1e9f4 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8130,38 +8130,75 @@ Reloading description configuration...done.
 	Menus
 
 	
-	  The Debian menu package provides a standard
-	  interface between packages providing applications and
-	  menu programs (either X window managers or
-	  text-based menu programs such as pdmenu).
+	  Packages shipping applications that comply with minimal requirements
+	  described below for integration with desktop environments should
+	  register these applications in the desktop menu, following the
+	  FreeDesktop standard, using text files called
+	  desktop entries.  Their format is described in the
+	  Desktop Entry Specification at
+	  http://standards.freedesktop.org/desktop-entry-spec/latest/;>
+	  and complementary information can be found in the
+	  Desktop Menu Specification at
+	  http://standards.freedesktop.org/menu-spec/latest/;>.
 	
 
 	
-	  All packages that provide applications that need not be
-	  passed any special command line arguments for normal
-	  operation should register a menu entry for those
-	  applications, so that users of the menu package
-	  will automatically get menu entries in their window
-	  managers, as well in shells like pdmenu.
+	  The desktop entry files are installed by the packages in the
+	  directory /usr/share/applications and the FreeDesktop
+	  menus are refreshed using dpkg triggers.  It is therefore
+	  not necessary to depend on packages providing FreeDesktop menu
+	  systems.
 	
 
 	
-  Menu entries should follow the current menu policy.
+	  Entries displayed in the FreeDesktop menu should conform to the
+	  following minima for relevance and visual integration.
+
+	  
+	
+	  Unless hidden by default, the desktop entry must point to a PNG
+	  or SVG icon with a transparent background, providing at least
+	  the  size, and preferably up to 6464.  The icon
+	  should be neutral enough to integrate well with the default icon
+	  themes.  It is encouraged to ship the icon in the default
+	  hicolor icon theme directories, or to use an existing
+	  icon from the hicolor theme.
+	
+
+	
+	  If the menu entry is not useful in the general case as a
+	  standalone application, the desktop entry should set the
+	  NoDisplay key to true, so that it can be
+	  configured to be displayed only by those who need it.
+	
+
+	
+	  In doubt, the package maintainer should coordinate with the
+	  maintainers of menu implementations through the
+	  debian-desktop mailing list in order to avoid problems
+	  with categories or bad interactions with other icons.  Especially
+	  for packages which are part of installation tasks, the contents
+	  of the NotShowIn/OnlyShowIn keys should be
+	  validated by the maintainers of the relevant environments.
+	
+	  
 	
 
 	
-	  The menu policy can be found in the menu-policy
-	  files in the debian-policy package.
-	  It is also available from the Debian web mirrors at
-  http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
+	  Since the FreeDesktop menu is a cross-distribution standard, the
+	  desktop entries written for Debian should be forwarded upstream,
+	  where they will benefit to other users and are more likely to
+	  receive extra contributions such as translations.
 	
 
-	
-	  Please also refer to the Debian Menu System
-	  documentation that comes with the menu
-	  package for information about how to register your
-	  applications.
+
+	  Packages can, to be compatible with Debian additions to some window
+	  managers that do not support the FreeDesktop standard, also provide a
+	  Debian menu file, following the Debian menu policy,
+	  which can be found in the menu-policy files in the
+	  debian-policy package.  It is also available from the Debian
+	  web mirrors at http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
 	
   
 
@@ -8169,42 +8206,109 @@ Reloading description c

Unidentified subject!

[Don Armstrong]

clone 741573 -1
reassign -1 debian-policy
retitle -1 Deprecating menu files and transition to desktop files
thanks

In #741573, the CTTE has determined that Debian should use .desktop
files as appropriate.

We had intended that this decision would start a discussion of the
policy necessary to generate this transition, using the changes in
https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
(attached).

I'm now trying to start that discussion in the hopes of generating a
changeset to policy which in addition to incorporating the CTTE changes
provides the framework for an orderly transition from the Debian menu
system to desktop standard.

I hope that this will happen within the normal policy discussion
framework in a reasonable timeframe; baring that, I will implement the
CTTE decision by applying ba679bff76 and NMUing policy.

-- 
Don Armstrong  http://www.donarmstrong.com


From ba679bff76f5b9152f43d5bc901b9b3aad257479 Mon Sep 17 00:00:00 2001
From: Charles Plessy <ple...@debian.org>
Date: Sat, 15 Feb 2014 11:12:30 +0900
Subject: [PATCH] Document the FreeDesktop menu entries and media type
 declarations.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Debian menu is optionally supported.

Wording: Charles Plessy <ple...@debian.org>
Seconded: Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com>
Seconded: Cyril Brulebois <k...@debian.org> (for the menu entries)
Seconded: Russ Allbery <r...@debian.org>
Closes: #707851
---
 policy.sgml | 200 +---
 1 file changed, 152 insertions(+), 48 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index dad8d23..1743552 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8054,38 +8054,75 @@ Reloading description configuration...done.
 	Menus
 
 	
-	  The Debian menu package provides a standard
-	  interface between packages providing applications and
-	  menu programs (either X window managers or
-	  text-based menu programs such as pdmenu).
+	  Packages shipping applications that comply with minimal requirements
+	  described below for integration with desktop environments should
+	  register these applications in the desktop menu, following the
+	  FreeDesktop standard, using text files called
+	  desktop entries.  Their format is described in the
+	  Desktop Entry Specification at
+	  http://standards.freedesktop.org/desktop-entry-spec/latest/;>
+	  and complementary information can be found in the
+	  Desktop Menu Specification at
+	  http://standards.freedesktop.org/menu-spec/latest/;>.
 	
 
 	
-	  All packages that provide applications that need not be
-	  passed any special command line arguments for normal
-	  operation should register a menu entry for those
-	  applications, so that users of the menu package
-	  will automatically get menu entries in their window
-	  managers, as well in shells like pdmenu.
+	  The desktop entry files are installed by the packages in the
+	  directory /usr/share/applications and the FreeDesktop
+	  menus are refreshed using dpkg triggers.  It is therefore
+	  not necessary to depend on packages providing FreeDesktop menu
+	  systems.
 	
 
 	
-  Menu entries should follow the current menu policy.
+	  Entries displayed in the FreeDesktop menu should conform to the
+	  following minima for relevance and visual integration.
+
+	  
+	
+	  Unless hidden by default, the desktop entry must point to a PNG
+	  or SVG icon with a transparent background, providing at least
+	  the  size, and preferably up to 6464.  The icon
+	  should be neutral enough to integrate well with the default icon
+	  themes.  It is encouraged to ship the icon in the default
+	  hicolor icon theme directories, or to use an existing
+	  icon from the hicolor theme.
+	
+
+	
+	  If the menu entry is not useful in the general case as a
+	  standalone application, the desktop entry should set the
+	  NoDisplay key to true, so that it can be
+	  configured to be displayed only by those who need it.
+	
+
+	
+	  In doubt, the package maintainer should coordinate with the
+	  maintainers of menu implementations through the
+	  debian-desktop mailing list in order to avoid problems
+	  with categories or bad interactions with other icons.  Especially
+	  for packages which are part of installation tasks, the contents
+	  of the NotShowIn/OnlyShowIn keys should be
+	  validated by the maintainers of the relevant environments.
+	
+	  
 	
 
 	
-	  The menu policy can be found in the menu-policy
-	  files in the debian-policy package.
-	  It is also available from the Debian web mirrors at
-  http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
+	  Since the FreeDesktop menu is a cross-distribution standard, the
+	  desktop entries written 

Bug#707851: Please resume discussion on #707851 or defer decision to the TC.

[Don Armstrong]

On Thu, 13 Mar 2014, Josselin Mouette wrote:
 Le jeudi 13 mars 2014 à 08:36 +0900, Charles Plessy a écrit : 
  I am therefore asking you to resume the discussion on #707851, or to defer 
  the
  decision to the technical comittee.
 
 I don’t think there is anything to discuss anymore. This is not
 relevant for the technical committee either, since a resolution by
 consensus has been attempted *with success*.

If everyone doesn't agree, then it's not a consensus resolution.

That said, a pocket veto isn't a valid approach either; if there's no
response, it should be assumed that consensus has indeed been reached.
If there is an objection, then the CTTE can be invoked at that point.

-- 
Don Armstrong  http://www.donarmstrong.com

I'm So Meta, Even This Acronym
-- xkcd http://xkcd.com/917/


-- 
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/20140313184939.gj...@teltox.donarmstrong.com

Re: Built-Using, libgcc, and libc_nonshared

[Don Armstrong]

On Thu, 23 May 2013, Steve Langasek wrote:
 FWIW, my understanding is that this is one of the issues that GPLv3
 attempted to bugfix with its clarification of the System Libraries
 exception. So to the extent that this is an issue, I believe it only
 applies to works that are GPLv2 only.

Right. This is one of the many reasons why GPLv2-only works are
problematic when they link with works under non-GPLv2 compliant licenses
without appropriate licensing exceptions.


-- 
Don Armstrong  http://www.donarmstrong.com

NASCAR is a Yankee conspiracy to keep you all placated so the South
won't rise again.
 -- http://www.questionablecontent.net/view.php?comic=327


-- 
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/20130523213431.gl26...@rzlab.ucr.edu

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

[Don Armstrong]

On Wed, 10 Apr 2013, Simon McVittie wrote:
 hat class=native-en_GB-speaker
 I've mostly seen whitespace used as a mass noun, like water or
 sand: you can say whitespace is ignored or a sequence of
 whitespace, but not a whitespace or whitespaces, in the same
 way that it's correct to say some sand, a piece of sand or a
 cubic metre of sand, but not a sand or sands.

Slight nitpick: you can (almost) always refer to collections of mass
nouns in a plural form. So whitespaces and sands are perfectly
reasonable to use, but then they refer to multiple separate
whitespace-containing areas, or multiple separate sand-containing
areas.


Don Armstrong

-- 
Only one creature could have duplicated the expressions on their
faces, and that would be a pigeon who has heard not only that Lord
Nelson has got down off his column but has also been seen buying a
12-bore repeater and a box of cartridges.
 -- Terry Pratchet _Mort_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20130410161904.gm15...@teltox.donarmstrong.com

Bug#701081: debian-policy: mandate an encoding for filenames in binary packages

[Don Armstrong]

On Fri, 29 Mar 2013, Russ Allbery wrote:
 I think we should require UTF-8 as the character encoding for file
 names and fix the non-UTF-8 file names in the archive currently.
 None of the other courses of action really make any sense to me.

I think we should also forbid the use of non ASCII file names in PATH
and recommend that ASCII file names be used where possible, but I also
agree that where ASCII cannot serve, only UTF-8 should be used.


Don Armstrong

-- 
Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20130401173919.gz4...@rzlab.ucr.edu

Re: What is the use case for Policy §7.6.2 ?

[Don Armstrong]

On Fri, 09 Nov 2012, Russ Allbery wrote:
 That makes sense to me on first glance. I can't think of a case
 where I'd want to use Provides/Conflicts/Replaces with non-virtual
 packages rather than using a transitional package.

I'm currently using this in the case of unscd and nscd.

It's useful to be able to do this when there are not any versioned
dependencies on the provided package, and one needs to take over the
configuration files of the package that is being conflicted with.

Just forbidding P/C/R in when there are (potentially) versioned
dependencies should be enough, I think.


Don Armstrong

-- 
life's not a paragraph
And death i think is no parenthesis
 -- e.e. cummings Four VII _is 5_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121109183941.gh11...@rzlab.ucr.edu

Re: Bug#681419: Alternative dependencies on non-free packages in main

[Don Armstrong]

forward 681419 
http://git.donarmstrong.com/?p=debian-ctte.git;a=blob;f=681419_free_non_free_dependencies/681419_free_non_free_dependencies.org
thanks

I've been going through and doing summaries for the current status of
the CTTE bugs; this is my understanding of where we are for 681419:

* Issue http://bugs.debian.org/681419
** May packages in main have a Depends: foo | foo-nonfree
* Possible Solutions
** Yes
   + Possibility of automatically pulling in non-free during some
 dependency resolution
** Yes, with caveats
   + Under no circumstances should non-free be pulled in automatically
*** Automatic: avoid in Release file
+ http://lists.debian.org/msgid-search/20120717083004.GB21400@frosties
*** Only virtual packages
** No
   + Lots of packages will be insta-buggy
* Open Questions
** How many total dependencies are there?  (We're only interested in Depends or 
Recommends for this purpose, not Suggests.)
*** 79
** Are all of those dependencies alternative dependencies of the form: Depends: 
foo | foo-nonfree or are there other cases?
*** Yes, save for two bugs
** Are any of these dependencies versioned?
*** No
** What do packages already in the archive do?
*** Already some alternative Depends: and Recommends: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681419#100
** Do any packages pull in non-free automatically already?
*** Apparently, no http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681419#100
* Involved Parties
** debian-policy@lists.debian.org



Don Armstrong

-- 
Live and learn
or die and teach by example
 -- a softer world #625
http://www.asofterworld.com/index.php?id=625

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120720192050.ge32...@rzlab.ucr.edu

Re: Proposal to update NMU section 5.11.1

[Don Armstrong]

On Thu, 26 Apr 2012, gregor herrmann wrote:
 On Wed, 25 Apr 2012 09:33:31 +0900, Charles Plessy wrote:
 
  Talking about improvements, if the following part about NMU acknowledgement 
  is
  obsolete as I think, how about removing it, either as a separate bug, or as
  part of the general refresh of the section that is discussed here.
  
To acknowledge an NMU, include its changes and changelog entry in your 
  next
maintainer upload. If you do not acknowledge the NMU by including the NMU
changelog entry in your changelog, the bugs will remain closed in the BTS 
  but
will be listed as affecting your maintainer version of the package. 
 
 Is this obsolete? In my understanding this is still how the BTS
 works; but I might have missed any changes.

Yes, that's still how the BTS works. Otherwise, the MU is a descendant
of the previous MU instead of the NMU. You can alternatively just
include the changelog entries from the NMU too. Either works.


Don Armstrong

-- 
-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
 -- e.e. cummings XXXIX _1 x 1_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120425231950.gm3...@rzlab.ucr.edu

Re: Proposal to update NMU section 5.11.1

[Don Armstrong]

On Thu, 26 Apr 2012, Charles Plessy wrote:
 Le Wed, Apr 25, 2012 at 04:19:50PM -0700, Don Armstrong a écrit :
  Yes, that's still how the BTS works. Otherwise, the MU is a
  descendant of the previous MU instead of the NMU. You can
  alternatively just include the changelog entries from the NMU too.
  Either works.
 
 Thanks for the information, I thought it was obsoleted when the
 closing of bugs became versioned.

It's a consequence of how versioning works.
 
 Can you describe somewhere what the BTS is doing on that matter ?  I do not
 understand the rationale and the function.

Versioning is a directed acyclic graph. Each version has at most one
ancestor, though it may have many descendants. When you upload a
maintainer upload (MU) without including the NMU changelog entry, you
are indicating that your version is a descendant of the previous MU,
not the NMU. That's perfectly ok, but if you've actually fixed bugs
that were fixed in the NMU in your MU, you need to include lines in
the changelog to that effect, or later on manually fix-up the
versions.

  Also, I thought that changelog-driven interaction with the BTS was
 only carried through dpkg-genchanges and dak...

Yes, that's correct.

 Can missing acknowledgements be corrected via the email interface ?

No. [In the sense that you can't change the DAG after it has been sent
from dak to the BTS. You can fix up mistakes in the found/fixed
versions, though.]

 Are there other direct interactions between a package and the BTS
 with its changelog ?

The BTS only sees the snippets of the changelog that dak presents to
the BTS. [And then the e-mails that dak sends to nnn-close@bdo, but
those merely close the bug in a version and don't affect the DAG.]
 

Don Armstrong

-- 
Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman What is and What Should be the Role of Scientific
Culture in Modern Society; 1964

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20120426003811.gn3...@rzlab.ucr.edu

Bug#670362: Stable updates section outdated

[Don Armstrong]

Package: developers-reference
Severity: minor
Tag: patch

The attached patch updates the developers reference to direct people
to file a bug using reportbug instead of mailing debian-release.


Don Armstrong

-- 
It seems intuitively obvious to me, which means that it might be wrong
 -- Chris Torek

http://www.donarmstrong.com  http://rzlab.ucr.edu
From 107c53c58ae60600898d8bd2f3890115856765c7 Mon Sep 17 00:00:00 2001
From: Don Armstrong d...@donarmstrong.com
Date: Tue, 24 Apr 2012 16:25:20 -0700
Subject: [PATCH] Upgrades to stable should be discussed using the
 release.debian.org pseudopackage and reportbug. See
 http://lists.debian.org/debian-devel-announce/2009/09/msg5.html
 for details

---
 developers-reference/pkgs.dbk |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/developers-reference/pkgs.dbk b/developers-reference/pkgs.dbk
index 8964d61..b59d03f 100644
--- a/developers-reference/pkgs.dbk
+++ b/developers-reference/pkgs.dbk
@@ -311,8 +311,8 @@ point release.
 /para
 para
 To ensure that your upload will be accepted, you should discuss the changes
-with the stable release team before you upload. For that, send a mail to
-the email-debian-release; mailing list, including the patch you want to
+with the stable release team before you upload. For that, file a bug against
+the release.debian.org pseudopackage using reportbug, including the patch you want to
 apply to the package version currently in literalstable/literal. Always
 be verbose and detailed in your changelog entries for uploads to the
 literalstable/literal distribution.
-- 
1.7.10

Bug#593533: debian-policy: Proposal to stop requesting to list initial Debian maintainers in debian/copyright

[Don Armstrong]

On Tue, 29 Nov 2011, Jakub Wilk wrote:
 * Charles Plessy ple...@debian.org, 2011-11-29, 09:07:
 p
   In addition, the copyright file must say where the upstream
 - sources (if any) were obtained.  It should name the original
 - authors of the package and the Debian maintainer(s) who were
 - involved with its creation.
 + sources (if any) were obtained, and should name the original
 + authors.
 /p
 
 Seconded. I've never understood why the initial packagers are
 special-cased.

I don't think that initial packagers should be special-cased, but the
copyright and licensing status of the packaging should be made clear
in the copyright file to the extent possible.

How to do this without making all packages instantly buggy, though, is
tricky.


Don Armstrong

-- 
People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide.
 -- John Brown, DEA Chief

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/2030001026.gc19...@rzlab.ucr.edu

Bug#593533: debian-policy: Proposal to stop requesting to list initial Debian maintainers in debian/copyright

[Don Armstrong]

On Tue, 29 Nov 2011, Russ Allbery wrote:
 Don Armstrong d...@debian.org writes:
  I don't think that initial packagers should be special-cased, but the
  copyright and licensing status of the packaging should be made clear in
  the copyright file to the extent possible.
 
 I think that's actually handled by the previous paragraph:
 
 p
   Every package must be accompanied by a verbatim copy of its
   copyright information and distribution license in the file
   file/usr/share/doc/varpackage/var/copyright/file. This
   file must neither be compressed nor be a symbolic link.
 /p
 
 not that everyone realizes that would apply to the Debian packaging files
 as well as the upstream source.

True. With that interpretation, it kind makes eliminating the
requirement for the original packager not to be mentioned a null-op
except for cases where the original packager has no copyright interest
in all (most?) jurisdictions. Perhaps a footnote clarifying this is in
order?


Don Armstrong

-- 
Never underestimate the power of human stupidity. 
 -- Robert Heinlein

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/2030003317.gd19...@rzlab.ucr.edu

Bug#593611: Acknowledgement (debian-policy: Clarify whose signature should go in debian/changelog (4.4))

[Don Armstrong]

On Thu, 02 Sep 2010, Bill Allombert wrote:
 I would rather suggest:
 
   The maintainer name and email address used in the changelog
   should be the details of the person who made the last change
   to this version of the package.
 
 I think this matches the actual use.

We're getting closer to the backyard[1] here, but the last change
could be terribly minor, and the person making that change may not
actually have primary responsibility for that version of the package.

Alternatively, if you're invoking the tautology, where the last step
is to sign the changelog, so the person who signs the changelog is the
person whose name is there, I agree, but don't think that's important
enough to document.


Don Armstrong

1: Or wherever the bikeshed is located
-- 
We must realize that today's Establishment is the New George III.
Whether it will continue to adhere to his tactics, we do not know. If
it does, the redress, honored in tradition, is also revolution.
 -- William O. Douglas _Points of Rebellion_

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/20100902193138.gi22...@rzlab.ucr.edu

Bug#593611: Acknowledgement (debian-policy: Clarify whose signature should go in debian/changelog (4.4))

[Don Armstrong]

On Sat, 21 Aug 2010, Raphael Hertzog wrote: 
 I don't quite like the notion of primarily responsible for the
 preparation of this version, it's rather blur for packages that are
 team maintained. In fact, the uploader might be the one who has done
 the least...

Sure, but whoever signs the changelog actually takes primary
responsiblity, even if they didn't do all of the work (or barely any
work). Perhaps s/the preparation of// would be even clearer.

But it honestly doesn't really matter to me whichever wording is
selected.


Don Armstrong

-- 
Tell me something interesting about yourself.
Lie if you have to.
 -- hugh macleod http://www.gapingvoid.com/archives/batch20.php

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/20100821072040.ga17...@teltox.donarmstrong.com

Bug#593611: Acknowledgement (debian-policy: Clarify whose signature should go in debian/changelog (4.4))

[Don Armstrong]

On Thu, 19 Aug 2010, Felipe Sateler wrote:
 Policy 4.4 currently says:
 
  The maintainer name and email address used in the changelog should be
  the details of the person uploading this version. They are not
  necessarily those of the usual package maintainer.
 
 One person I'm sponsoring misread this and put my name in the
 changelog, since I'm the one actually doing the upload. I can't
 think of a better wording, though. Perhaps a footnote is enough?

 The maintainer name and email address used in the changelog should be
 the details of the person uploading _this_ version.

Perhaps changing it to

 The maintainer name and email address used in the changelog
 should be the details of the person primarily responsible for the
 preparation of this version.
 
In the most usual case, the person doing the preparation is also the
person doing the upload, but it need not be the case. AFAICT, this
also documents current standard practice even in team maintained
packages.


Don Armstrong

-- 
Our days are precious, but we gladly see them going
If in their place we find a thing more precious growing
A rare, exotic plant, our gardener's heart delighting
A child whom we are teaching, a booklet we are writing
 -- Frederick Rükert _Wisdom of the Brahmans_ 
 [Hermann Hesse _Glass Bead Game_]

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
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/20100819230520.gx17...@teltox.donarmstrong.com

Bug#556015: Clarify requirements for copyright file

[Don Armstrong]

On Wed, 07 Jul 2010, Jakub Wilk wrote:
 This encourages arch:any - arch:all symlinks, which is exactly what
 I wanted to be disallowed.

If we're going to allow any symlinks, these are the ones that are most
advantagous to allow, because otherwise we're duplicating
documentation and copyrights in all of our architectures instead of
just having them present once.

I think there's some confusion here; debian/control documents changes
to the source package, and as such, should always have the source
version listed. [Binnmus have a changelog revision, but this is
technically a violation, as their source version is not Y+bNN, but Y.]


Don Armstrong

-- 
Of course Pacman didn't influence us as kids. If it did, we'd be
running around in darkened rooms, popping pills and listening to
repetitive music.

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/20100707185951.gv27...@teltox.donarmstrong.com

Bug#556015: Clarify requirements for copyright file

[Don Armstrong]

On Wed, 07 Jul 2010, Steve Langasek wrote:
 On Wed, Jul 07, 2010 at 11:59:51AM -0700, Don Armstrong wrote:
  I think there's some confusion here; [debian/changelog] documents changes
  to the source package, and as such, should always have the source
  version listed. [Binnmus have a changelog revision, but this is
  technically a violation, as their source version is not Y+bNN, but Y.]
 
 I think this technical violation is a bug in policy, not in binNMU
 practices.

I'd be fine with a specific exception for binNMUs, but not a more
general one, as the ability to reconstruct a version graph based on
the source version entries in debian/changelog is fairly important for
the BTS. [It's of less importance now that dak exports that to the
BTS, but it is still how we generated it all in the first place.]


Don Armstrong

-- 
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
 -- Patrick McGoohan as Number 6 in The Prisoner

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/20100708004840.gz27...@teltox.donarmstrong.com

Bug#556015: Clarify requirements for copyright file

[Don Armstrong]

On Mon, 05 Jul 2010, Russ Allbery wrote:
 Well, they do, in that binNMUs do change the changelog included in
 the package. I'm inclined to agree that it's not a big deal if we
 lose that information in the installed package, though.

Right; this is kind of an odd thing, because a binNMU has a source
version which doesn't match the entry in the changelog.

 any - any can use (= ${binary:Version})
 any - all can use (= ${source:Version})
 all - all can use (= ${source:Version})
 
 The question is what to do for all - any.  Right now, I think best
 practice is to do something like:
 
 (= ${source:Version}), ( ${source:Version}+b99)

In general, if you had an arch all package which had to be installed,
it should have the changelog in it, and the arch any package wouldn't.

The only exception I can see is a case where the arch: all package
wouldn't be a dependency of the arch: any package, but the arch: all
package requires functionality in the arch: any package (and there
isn't any required arch: all package from the same source). [Like a
source package which builds a core set of binaries, and an -examples
package of perl scripts which needs the core set to function.]


Don Armstrong

-- 
Personally, I think my choice in the mostest-superlative-computer wars
has to be the HP-48 series of calculators.  They'll run almost
anything.  And if they can't, while I'll just plug a Linux box into
the serial port and load up the HP-48 VT-100 emulator.
 -- Jeff Dege, jd...@winternet.com

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/20100706075214.gw27...@teltox.donarmstrong.com

Bug#556015: Clarify requirements for copyright file

[Don Armstrong]

On Sun, 04 Jul 2010, Russ Allbery wrote:
 Here's the question: should we say flat-out that both packages must
 either be architecture-dependent or architecture-independent and
 then say that the dependency must use (= version), or should we
 allow what I was trying to allow above and then document, such as in
 a footnote, the technique of depending on (= version), (
 version+b99)? The latter, as mentioned, may hide binNMU changelog
 entries.

The changelog really documents the changes in the versions of the
source package, not changes in the binary package. Since a binary
rebuild doesn't involve any changes to the source package, it should
be ok to link to the same changelog. In all such cases, you should
have an exact dependency on the source version of the architecture
independent package, which needs to be the same as its binary version.
(In the case of an architecture dependent package, it should be the
binary version, of course.)


Don Armstrong

-- 
Life would be way easier
if I were easier.
 -- a softer world #473
http://www.asofterworld.com/index.php?id=473

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
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/20100706014024.gv27...@teltox.donarmstrong.com

Bug#580135: [debian-policy] 12.7 Changelog files shouldn't advise the use of lynx

[Don Armstrong]

On Mon, 03 May 2010, David Prévot wrote:
 In order to include upstream changelog distributed in HTML, and convert
 it as a plain text changelog.gz, policy should advise the use of
 html2txt (which debhelper already depends on) rather than lynx that has
 fewer chance to already be on Build-Depends:.

html2text by default[1] produces output which is decidedly suboptimal
in comparsion to the default lynx output.

For comparison, lynx output (from www.debian.org):

Getting Started

   The latest stable release of Debian is 5.0. The last update to this
   release was made on January 30th, 2010. Read more about available
   versions of Debian.

   If you'd like to start using Debian, you can easily obtain a copy, and
   then follow the installation instructions to install it.

html2text output:

* Getting Started *
The latest_stable_release_of_Debian is 5.0. The last update to this release was
made on January 30th, 2010. Read more about available_versions_of_Debian.
If you'd like to start using Debian, you can easily obtain_a_copy, and then
follow the installation_instructions to install it.


I've no problem with html2text being suggested in addition to lynx
-dump -nolist, but I'm not convinced that it should be the default.


Don Armstrong

1: I'm fairly sure there's some way to provide a style file which
actually renders it reasonably...
-- 
PowerPoint is symptomatic of a certain type of bureaucratic
environment: one typified by interminable presentations with lots of
fussy little bullet-points and flashy dissolves and soundtracks masked
into the background, to try to convince the audience that the goon
behind the computer has something significant to say.
 -- Charles Stross _The Jennifer Morgue_ p33

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
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/20100503201920.gb8...@teltox.donarmstrong.com

Re: Question of legal usage Debian GNU/Linux in Ukraine

[Don Armstrong]

On Tue, 09 Feb 2010, Dmitry Korzhevin wrote:
 I ask you to give an answer and an explanation of possible legal and
 free use, copying and distribution of the operating system Debian
 GNU/Linux in Ukraine.

We are not able to provide you with specific legal advice with regards
to the legality and/or use of the operating system that we distribute,
unfortunately.

That said, we have made an effort to make sure that the software that
we distribute in main is available under terms which satisfy the
Debian Free Software Guidelines,[1] which requires that works in
Debian be freely redistributable, modifiable, and freely used.

See http://www.debian.org/intro/free as well for more information.

Finally, debian-policy@lists.debian.org is not the appropriate list
for this kind of question; -project or possibly -legal is.
[Additionally, our website has answers to these specific questions,
even in українська.]


Don Armstrong

1: http://www.debian.org/social_contract#guidelines
-- 
The carbon footprint of a single human being is enormous.
If you think about it, your honour,
I'm an environmentalist.
 -- a softer world #283
http://www.asofterworld.com/index.php?id=283

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#568313: Suggestion: forbid the use of dpkg-statoverride in postinst scripts, except for --list

[Don Armstrong]

On Wed, 03 Feb 2010, Brandon wrote:
 First, I suggest that Debian Policy require, or at least recommend,
 that packages not use dpkg-statoverride to set permissions for files
 with static uids and gids. In other words, if it is possible for the
 maintainer to set the permissions in the package binary itself, then
 he should.

What is the rationale for this? What set of packages currently
existing would be instantly buggy if this were the case?

 As for setting permissions for files with dynamic ids, debian policy
 says that dpkg-statoverride is necessary. This is not true, or at
 least misleading. Certainly the post install script should check to
 make sure that there isn't any override in place before setting file
 permissions, but I think it would be better to set permissions with
 chown and chmod than dpkg-statoverride.

This is a bad idea. There's no advantage to using chown and chmod over
dpkg-statoverride. In fact, you have to do more work, because you have
to check all of the things that dpkg-statoverride gets you for free,
like making sure that dpkg-statoverride hasn't previously been set.

It also means that there will be a relatively long time when the
package has been unpacked with the wrong permissions set until the
postinst is called to fix them up.


Don Armstrong

-- 
Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#568313: Suggestion: forbid the use of dpkg-statoverride in postinst scripts, except for --list

[Don Armstrong]

On Thu, 04 Feb 2010, martin f krafft wrote:
 I can perfectly understand admins wanting to override package
 defaults, but not why the package maintainer needs to use
 dpkg-statoverride.

You need to use dpkg-statoverride when you are using a dynamic uid/gid
and files that you ship need to be setuid/setgid to that uid/gid, or
when you've got a sensible default of not setgid (or similar) but you
want that setting to be easily configurable via debconf.


Don Armstrong

-- 
There's no problem so large it can't be solved by killing the user
off, deleting their files, closing their account and reporting their
REAL earnings to the IRS.
 -- The B.O.F.H..

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#568313: Suggestion: forbid the use of dpkg-statoverride in postinst scripts, except for --list

[Don Armstrong]

On Wed, 03 Feb 2010, Brandon wrote:
 I bet there will be several. On my system currently, xcdroast and

I think this is a holdover from when xcdroast asked a debconf
question; it's probably a bug that that code is still there... file
it!

 xsendmail use stat overrides unnecessarily.

I don't know about an xsendmail package; sendmail itself doesn't do
this. (Or at least, it doesn't any more.)

The reason why I'm asking this question is because before policy is
changed into a must requirement, someone should have found out which
packages will be instantly RC buggy.


Don Armstrong

-- 
People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide.
 -- John Brown, DEA Chief

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Effect of “should ce rtainly do foo” in policy

[Don Armstrong]

On Fri, 29 Jan 2010, Russ Allbery wrote:
 Basically, it would be nice to have a standard terminology to distinguish
 between the following states:
 
 1. You must (or must not) do this, and doing otherwise is an RC bug.
 
 2. You must (or must not) do this, but doing otherwise is a normal (or
important, or minor) bug.
 
 3. You should (or should not) do this unless you really know what you're
doing and have thought about the consequences, but there are some
legitimate exception cases.
 
 4. You're explicitly permitted to do this (used primarily when something
else could be read as implying that you're not allowed to do so, or to
be clear about what other software can assume).
 
 RFC 2119 says that the first is MUST, the third is SHOULD, and the fourth
 is MAY.  It doesn't have a keyword for the second case.  We currently use
 must for the first case, should for the second case, and may for the
 fourth case and have no keyword for the third case (but sometimes reuse
 should to mean that as well).

I think it would be a good idea to capitalize (or otherwise emphasize)
these terms when they are making a state as is typically done in RFCs.

To avoid using should for #3 as well as #2, we could use OUGHT/OUGHT
NOT (or some other similar phrase; NEEDS may also work.) [We could
also use should for #3, and ought for #2, but AFAICT, most of us
assume that should means #2, with some shades of #3.]

I agree that phrases like this would make policy more readable. It
also has the benifit of coupling each requirement/statement to the
severity of a bug when writing tests to check for compliance with each
requirement/statement.
 

Don Armstrong

-- 
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
  -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: does /var/games have to be deleted on purge? (if it's empty..)

[Don Armstrong]

On Wed, 06 Jan 2010, Bernhard R. Link wrote:
 Your data in in $HOME.

Not all data is in $HOME. I have lots of data which is in /srv,
/var/www, or other places, some of which is tightly coupled with a
specific set of packages.

 On other words: as a quick test: if I only use a program as user and
 purge the package and my $HOME (and perhaps /tmp by reboot), there
 should be nothing left and especially when I reinstall it everything
 should be as after the first installation.

There are lots of cases where packages legitimately fail this test.
Any change to this policy needs to account for the corner cases where
users have created or modified user data which should be preserved.

If the data was not created by the package during installation or has
been subsequently modified by the user and is likely to be of some
degree of importance, it should not be removed, even on purge, without
the specific direction of the administrator.

That said, to the extent possible, packages should remove data which
was created by the package during installation which has not been
modified by the end user or is unlikely to be of any importance.


Don Armstrong

-- 
EQUAL RIGHTS FOR WOMEN
Don't be teased or humiliated. See their look of surprise when you
step right up to a urinal and use it with a smile. Get Dr. Mary Evers'
EQUAL-NOW Adapter (pat. appld. for) -- purse size, fool proof,
sanitary -- comes in nine lovely, feminine, psychedelic patterns --
requires no fitting, no prescriptions.
 -- Robert A Heinlein _I Will Fear No Evil_ p470.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: does /var/games have to be deleted on purge? (if it's empty..)

[Don Armstrong]

On Mon, 04 Jan 2010, Holger Levsen wrote:
 On Montag, 4. Januar 2010, Russ Allbery wrote:
  * It's sometimes necessary to purge a package and reinstall it to
fix some weird problem, or if not necessary at least expedient.
For example, if one accidentally deletes a configuration file,
one of the faster ways to get the original configuration file
shipped with the package back is to purge and reinstall the
package. It saves unpacking the package somewhere and manually
copying out the configuration file.

For this, you actually should be using --force-confmiss.

 Basically see my answers to previous two arguments. IMHO purging
 should do what it's designed to do.

This entire discussion is about what purging should be designed to do.

There are lots of examples of data which is has significant user
contribution but is coupled to varying degrees to a package (or even
multiple packages).

Consider data in /var/www, for example, or collections of mysql
databases created by versions of mysql which have been partially
replaced by subsequent versions of mysql. Or ldap databases which were
created by openldap, but are now being used by some other ldap
replacement (or some custom scripts).

Purge should clean up detrius, but there is always a balance between
completely cleaning out the detrius and destroying user data which may
be wanted.


Don Armstrong

-- 
Everyone has to die. And in a hundred years nobody's going to inquire
just how most people died. The best thing is to do it in the way that
strikes your fancy most.
 -- Kenzaburō Ōe _Silent Cry_ p5

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Silently breaking on upgrade

[Don Armstrong]

On Tue, 13 Oct 2009, The Wanderer wrote:
 That's what I'd have thought, but I've run across a package which does
 seem to do this, and the maintainer seems to consider it an acceptable
 situation. Before trying to argue too much about that, I wanted to
 confirm that it was in fact 'officially' considered unacceptable.

Breakage is a bug. In some cases fixing the breakage is not possible,
or would introduce other problems (or the breakage isn't even breakage
in the first place) so without knowing details, there's nothing else
we can say.


Don Armstrong

-- 
There are two types of people in this world, good and bad. The good
sleep better, but the bad seem to enjoy the waking hours much more.  
 -- Woody Allen

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.

[Don Armstrong]

On Mon, 05 Oct 2009, Charles Plessy wrote:
 As a user I strongly dislike to have to edit my scripts and command
 line sessions in order to make them usable for my colleagues, and I
 would be very annoyed if the first thing to do after installing a
 package would be to check if I have to change the PATH environment
 variable in my current sessions and my logins scripts.

The error here is upstream. Using language extensions in programs that
are part of a public API is wrong, and shouldn't be done. Fixing the
bug in Debian is only a partial solution. These bugs should also be
fixed upstream.

 But on the other hand, once this choice has been made and the
 program distributed, I think that the inconvenients of renaming only
 in Debian are higher than the advantages.

It shouldn't be renamed only in Debian. And even so, it's fairly
simple to work around in scripts even if upstream doesn't want to see
the light. which is your friend.

 Renaming is a practical disadvantage for the users and the package
 maintainers. What are the practical advantages?

The practical advantages are that 1) you can reimplement scripts
without renaming, 2) you don't make it more difficult on public users
of the binary who have to remember both the name and the entirely
arbitrary aspect of what language it was implemented in[1] and 3)
things are consistently named, no matter what the package is.

Furthermore, the policy is a *should* directive, not a *must*
directive. There are many cases where there are things that are done
wrongly, but fixing these historical mistakes are more costly than
living with them. A wontfix bug with possible lintian overrides may be
acceptable in such rare cases.

That said, most packages that are being added to Debian are relatively
new works, and don't have a huge historical userbase with legacy
scripts; fixing these sorts of issues upstream at the earliest
opportunity is the right way forward, and a should directive in policy
is the right way to inform everyone of what the proper practice is.


Don Armstrong

1: Obviously, tab completion works in interactive use, but it's
certainly not the case for writing scripts, documentation, or anything
else. If the code is only used interactively, then there's no real
downside to renaming it.
-- 
All bad precedents began as justifiable measures.
 -- Gaius Julius Caesar in The Conspiracy of Catiline by Sallust

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.

[Don Armstrong]

On Tue, 06 Oct 2009, Charles Plessy wrote:
 I think that the core of the disagreement is on how frequent the
 re-implementation in a different language happen. My experience is
 that in my field, bioinformatics, it is close to zero. Moreover,
 when programs with similar function and same basename are written,
 they are most often not designed to be a 'drop-in' replacement. The
 filename extension is therefore part of the name, and removing it
 only creates problems and difficulties. I will stop to obey the the
 'should' Policy directive, because I think that this is the right
 thing to do in my profesional environnement.

IME, the bioinformatics tools I've used tend to be written by people
with minimal experience in FOSS development;[0] as such they often
tend to do things in ways that don't properly integrate with the ways
things are done in existing FOSS distributions. Educating them and
promoting these changes upstream is an important part of stewarding
their incorporation in Debian. [In the few cases where I've run into
this problem, patches have been readily accepted upstream.]

I'd suggest reconsidering your stance, but since you're doing the
work, it's not something I'm going to push any harder about.
 
 If the developers who think that everybody in Debian should rename
 scripts with name suffix indicating a language have no other
 arguments to add, then indeed it is the moment to call for the
 technical commitee to take a final decision.

Changing policy without rough consensus would require a CTTE decision
on the matter. Since Russ and Manoj have both laid out their
objections to changing policy by removing the should directive, I
don't believe there is much hope in achieving rough consensus.
[Honestly, since 3/3 of the CTTE members who have commented on this[1]
have made their opinion fairly clear, I'm not sure if there's much
hope in that path either.]

 On my side, I am willing to make concessions, so a rewording of the
 should directive to explain when exceptions are acceptable could be
 an alternative. But my undertaning of a 'should' directive is that
 it would not make sense if they do not apply in most of the cases,
 which here is my point of view: the programs that the Policy wants
 me to rename do not in any way have the same scope as /bin/ls, nor
 are they as standardised and widely used enough that they could be
 called a part of a 'public API'.

If they are not standardized enough to be part of a public API, then
they do not belong in one of the directories in the system PATH, and
their name matters little. (Policy says nothing about the extensions
of executables outside of the system PATH for precisely this reason.)

If scripts are installed into the system PATH, then it's because
people who install those packages are expected to be able to make use
of them as a public API, and they should generally be treated as such.


Don Armstrong

0: Or alternatively, they're written by people like me who don't
think about other people's use of them much.
1: Possibly 3/4 or 4/4; I'm not quite sure what Steve's position is.
-- 
We must realize that today's Establishment is the New George III.
Whether it will continue to adhere to his tactics, we do not know. If
it does, the redress, honored in tradition, is also revolution.
 -- William O. Douglas _Points of Rebellion_

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.

[Don Armstrong]

On Tue, 06 Oct 2009, Charles Plessy wrote:
 Le Mon, Oct 05, 2009 at 06:33:53PM -0700, Don Armstrong a écrit :
  In the few cases where I've run into this problem, patches have
  been readily accepted upstream.
 
 Indeed, that is the way to go, and the core of my argument is that
 renaming before the patches are accepted is a deviation that wastes
 the time of our users (in that case, me).

Sure, but I'd expect that in most cases, a simple patch to upstream,
with a resultant ack for the next distribution should take a few days
at most. If there's a total rejection, then it's a bug, but it's most
likely wontfix.

In the cases where upstream is unresponsive that it takes more than a
few days to do the go-around, it probably shouldn't be being packaged
in the first place. [Or at least, it shouldn't be uploaded until the
upstream gets back to you.]

 Yes, at the beginning I was solving the problem by moving the
 scripts to /usr/share. But again, as a user of my own package, I was
 wasting my own time at work, and stopped doing this.

Perhaps it'd be useful for continued discussion if specific examples
of packages and executables hwich are installed to a system PATH which
you've needed to rename would help work through this.


Don Armstrong

-- 
All bad precedents began as justifiable measures.
 -- Gaius Julius Caesar in The Conspiracy of Catiline by Sallust

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548823: devref: please point to text file to get #debian-private password

[Don Armstrong]

On Mon, 28 Sep 2009, Ryan Niebur wrote:
 instead of wasting peoples time, making them read through
 debian-private list archives, trying 3 wrong passwords until they
 finally discover that they could have figured it out much, much easier
 if devref had not mislead them.

Sounds reasonable. I suggest providing a patch which makes this
change.


Don Armstrong

-- 
We were at a chinese resturant.
He was yelling at the waitress because there was a typo in his fortune
cookie.
 -- hugh http://www.gapingvoid.com/Moveable_Type/archives/000321.html

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543417: README.source patch system documentation requirements considered harmful

[Don Armstrong]

On Tue, 08 Sep 2009, Bernhard R. Link wrote:
 I think having short README.source is better than having none. If
 there is a short one in normal cases, people can always look at it
 and see at one glance whether it is what they expect or if it needs
 special consideration.

My main concern is maintainer time spent adding and maintaining the
file in many packages outstripping time saved by (as-of-yet)
non-maintainers. A secondary concern is reader fatigue, where the file
doesn't document anything that someone would normally already be aware
of, so people ignore it in general.

If we had a generic set of packaging types that we could agree didn't
need to be documented in README.source (perhaps in devref, with
pointers to the actual documentation?), the README.source could be
reserved for things which actually were unusual, and would obviate
most of the concerns raised.


Don Armstrong

-- 
THERE IS NO GRAVITY THE WORLD SUCKS
 -- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Don Armstrong]

On Tue, 18 Aug 2009, Manoj Srivastava wrote:
 Given these, I read this as letting the tools rely on
  the following invariants, even though these are not explicitly spelled
  out in so many words in policy:
 
  1)  If there is a - in the version number, then the package is
  non-native
   a) the upstream version is the part of the string until the last
  '-' in the version number 
   b) there is a .orig.tar.gz and
   c) diff.gz referenced in the .dsc

  2) If there is no '-' in the version number, then the package is a
 debian native package
   a) there is no debian revision, all the version number is the
  upstream version number
   b) there is a tar.gz and no diff.gz in the .dsc file

(1) is not necessarily true in the case of NMUs of native packages.[1]
The only way to tell if a package is native or not is to inspect the
.dsc. [So long as the as-yet-to-be-proposed wording is clear on this,
it should be a big deal.]

That said, the rest looks reasonable, but it would probably be useful
to make sure that we're actually representing current practice.
  

Don Armstrong

1: I've personally made a at least one of these before I was aware of
the +nmu1 option.
-- 
Three little words. (In descending order of importance.)
I
love
you
 -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538392: group staff: moving forward

[Don Armstrong]

On Wed, 12 Aug 2009, Santiago Vila wrote:
 No need to add configuration stuff. If a user wants something
 different than the default, he/she can easily make a chown and a
 chgrp.

chown and chgrp is exactly the method of configuration I mean.

 Let's keep it simple: Beginning squeeze, base-files will no longer
 create those directories with special permissions. I think this
 respects the principle of least surprise, as already created
 directories (from lenny) will be kept in whatever status they are.

That's the minimum. I think we need to go farther,[1] because that
doesn't transition existing installs.

If you don't have any non-root users in the staff group, I can't see
any reason to keep /usr/local 2775. If you do, you may have a problem;
we should warn about it, and ask about transitioning at some priority.
(It's fine if it's low priority.)


Don Armstrong

1: Or at least, we should strongly consider going farther; if it ends
up being untenable, so be it.
-- 
An elephant: A mouse built to government specifications.
 -- Robert Heinlein _Time Enough For Love_ p244

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538392: group staff: moving forward

[Don Armstrong]

On Tue, 11 Aug 2009, Santiago Vila wrote:
 Could we please move the default to 755, not 2775, like every other
 normal directory in Debian? There is little point in keeping those
 directories world-writable if they stop being owned by group staff.

The group for the directories can still be staff, it should just not
be writable by group staff by default [but configurable by users to
be, with that configuration respected.]

/usr/local isn't a normal subdirectory tree, as nothing should be
shipped in it by Debian packages.

I had assumed that basefiles would do something like the following:

1) if group staff has non-root users:
  - ask if /usr/local should be writable by staff
* yes: bail out; don't ask this question again
* no: continue to 2

2) make /usr/local and it's subdirectories which are root:staff 2775
   either 2755 or 0755, root:root or root:staff; don't really care
   which; don't do this step ever again upon completion.

packages making subdirectories of /usr/local would do something like;

3) if [ -e /path/to/foo/ ]; then
  if mkdir -m=$(stat -c %a /usr/local) /path/to/foo 2/dev/null; then
 chgrp $(stat -c %g /usr/local) /path/to/foo;
  fi;
   fi;

for each of the subdirectories created, as appropriate.


Don Armstrong

-- 
This isn't life in the fast lane, it's life in the oncoming traffic
 -- Terry Pratchett

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Don Armstrong]

On Mon, 10 Aug 2009, Manoj Srivastava wrote:
  Why is it not trivial?

Because it requires editing the rules file for each such package?
(debhelper using packages all get tweaked in a single shot.)


Don Armstrong

-- 
All my dreams came true.
I just didn't think them through.
 -- a softer world #388
http://www.asofterworld.com/index.php?id=388

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Don Armstrong]

On Mon, 10 Aug 2009, Manoj Srivastava wrote:
 On Mon, Aug 10 2009, Don Armstrong wrote:
  On Mon, 10 Aug 2009, Manoj Srivastava wrote:
   Why is it not trivial?
 
  Because it requires editing the rules file for each such package?
  (debhelper using packages all get tweaked in a single shot.)
 
 I suspect all cdbs using packages can be similarly tweaked

Uh... cdbs uses debhelper, so tweaking would be unecessary.

 Also, It is indeed trivial to add that to non-helper-package using
 packages, it just requires some editing (just like modufying helper
 packages will need editing).

Since it's trivial, I look forward to seeing patches from you to
implement policy once we decide it on all of the non-debhelper using
packages. [How many person-hours of labor are we talking about now?]


Don Armstrong

-- 
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
 -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: debian/copyright and Files-Within-Files

[Don Armstrong]

On Tue, 30 Jun 2009, Steve Langasek wrote:
 Is it not sufficient to just list
 
   Files: Stuff.tar.gz
   Copyright: 2005 Some Company A
  2002 Some Person B
  2002-2007 Other Fictional Entity
   License: Tar Public License

Or we could just do

Files: Stuff.tar.gz/foo.c
Copyright: Copyright 2005 Some Company A
License: ...

Files: Stuff.tar.gz/bar.txt
Copyright: Copyright 2002 Some Person B
License: ...

Files: Stuff.tar.gz/baz.c
Copyright: Copyright 2002-2007 Other Fictional Entity
License: ...

and then just treat files which are known to be tarballs (or some
other archive) as if they were unpacked directories.


Don Armstrong

-- 
You have many years to live--do things you will be proud to remember
when you are old.
 -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Syntax issues in Policy Manual

[Don Armstrong]

On Mon, 29 Jun 2009, Jeremiah Foster wrote:
 I understand why both you and Russ feel that way. But I would like
 to respectfully disagree. I think you would find in practive this
 might be an excellent opportunity for people to get involved.

What's most important isn't that more people get involved, it's that
policy itself is technically excellent and accurately describes how
packages ought to, should, and must function in Debian.

That said, anyone is free to submit patches to Debian's Policy, but
they must pass muster first.

 One can take the best parts of the wiki and cast them into pdf or
 html or something more permanent.

Feel free to shove a copy of Debian's Policy into a wiki somewhere and
use it as a mechanism to generate suggested patches for incorporation
into Policy itself; no one will (or can) stop you from doing that and
driving that effort.


Don Armstrong

-- 
Everyone has to die. And in a hundred years nobody's going to inquire
just how most people died. The best thing is to do it in the way that
strikes your fancy most.
 -- Kenzaburō Ōe _Silent Cry_ p5

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#533852: debian-policy: Allow Binary field to span over multiple lines

[Don Armstrong]

On Sun, 21 Jun 2009, Raphaël Hertzog wrote:
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -3276,7 +3276,9 @@ Package: libc6
 commasfootnote
 A space after each comma is conventional.
 /footnote. Currently the packages must be separated using
 -   only spaces in the file.changes/file file.
 +   only spaces in the file.changes/file file. The list can span

This should be changed to read file, and may wrap.

 +   over multiple lines if needed, in that case the linefeed
 +   characters are treated like spaces.

The above is superfluous.

It cannot be separated just by newlines, because it needs a leading
space or tab, and Policy 5.1 already specifies how to do that.


Don Armstrong

-- 
A Democracy lead by politicians and political parties, fails.

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#533287: debian-policy: please clarify 10.7.4

[Don Armstrong]

On Wed, 17 Jun 2009, Sune Vuorela wrote:
 so it seems that the alternative interpretation, is that if there
 is a interface, then it must be used, but all that is wrapped in a
 should, which is not as binding as a must.

While this section of policy could probably be clarified, violating a
should directive of policy is almost always a bug. It may be a bug in
the package, another package, or in policy itself. Still, somewhere in
the train, something is suboptimal and should be fixed.


Don Armstrong

-- 
No matter how many instances of white swans we may have observed, this
does not justify the conclusion that all swans are white.
 -- Sir Karl Popper _Logic of Scientific Discovery_

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#530378: debian-policy: allow /usr/share/doc/package to point to another indirectly-depended-upon package's dir

[Don Armstrong]

On Mon, 25 May 2009, Serafeim Zanikolas wrote:

 On Sun, May 24, 2009 at 06:10:03PM -0700, Russ Allbery wrote:
  I guess I'm not understanding why you don't just make bogofilter depend
  on bogofilter-common as well.  What's the drawback?
 
 None really, but it would seem as if we're making a technical
 decision for a bureaucratic reason, which doesn't seem right.

The technical reason to do it this way is that it makes it much easier
to test in lintian or similar; you just need to examine the target of
the symlink and see if the package depends on the package named in the
symlink target. [I'm not really sure where the bureaucracy is here.]


Don Armstrong

-- 
No matter how many instances of white swans we may have observed, this
does not justify the conclusion that all swans are white.
 -- Sir Karl Popper _Logic of Scientific Discovery_

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#530378: debian-policy: allow /usr/share/doc/package to point to another indirectly-depended-upon package's dir

[Don Armstrong]

On Sun, 24 May 2009, Serafeim Zanikolas wrote:
 Policy allows a package's doc directory to be a symlink to another package's
 doc directory, as long as they are:
 
 - from the same source package and
 - the first package directly depends upon the second
 
 I propose that that the second requirement is relaxed to allow for an indirect
 dependency of the first package to the second (as long as all packages
 involved have the same source).

I don't see the benefit of this. If you're going to have a symlink to
the doc directory of another package, you should have a dependency on
the package that provides the doc directory. [It makes it much easier
to test in lintian, and it makes it much less likely to result in
errors down the line where the package the dependency path goes
through drops the dependency.]


Don Armstrong

-- 
CNN/Reuters: News reports have filtered out early this morning that US
forces have swooped on an Iraqi Primary School and detained 6th Grade 
teacher Mohammed Al-Hazar. Sources indicate that, when arrested,
Al-Hazar was in possession of a ruler, a protractor, a set square and
a calculator. US President George W Bush argued that this was clear
and overwhelming evidence that Iraq indeed possessed weapons of math 
instruction.

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#521810: debian-policy: Document user defined fields starting with X-

[Don Armstrong]

On Tue, 31 Mar 2009, Raphael Hertzog wrote:
 On Mon, 30 Mar 2009, Russ Allbery wrote:
  Nils Rennebarth nils.renneba...@funkwerk-ec.com writes:
  
   Usually, unknown fields are iggnored by the debian packaging system. To
   avoid conflicts of user defined fields with field that may be used by
   debian in the future, we suggest to use field names starting with X- (so
   you need to put X[BCS]-X-foo into the control file) which are guaranteed
   to never conflict with future official fields.
  
  Is this because the X in front of [BCS] is stripped off when the field is
  copied into the resulting binary or source package?
 
 Yes.

Is there any reason why we can't transition official X-* headers to
real * headers as they become widely used (and when they're inshrined
in policy)?

Some transition period would be necessary, and dpkg-gencontrol could
be patched to automatically rename the X-* headers to * for the
transition period (and tools that use the header should look at both
X-* and * headers[0]).

We really don't have the issue of email, because we have a relatively
consistent set of tools that actually generate control (for non-Manoj
developers anyway[1]).


Don Armstrong

0: I submit that tools that examine the headers should let the *
header override the X-* header when they're being written, unless
there's some extraordinary reason not to do so.

1: Manoj may even use dpkg-gencontrol now...
-- 
Physics is like sex. Sure, it may give some practical results, but
that's not why we do it.
 -- Richard Feynman

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Goals of debian/copyright

[Don Armstrong]

On Wed, 25 Mar 2009, Mike Hommey wrote:
 On Tue, Mar 24, 2009 at 02:56:57PM -0700, Don Armstrong wrote:
  I think we're getting bogged down in the debian/copyright discussion,
  and I'm starting to think that some enumeration of what we need
  debian/copyright for would help us figure out what it should actually
  contain.
  
  I've listed the things that I remember from the relevant threads (and
  my personal recollection):
  
  1) DFSG Free licensing of all parts distributed by Debian in main
  
  2) License compatibility (both intra-work and inter-work)
  
  3) Satisfy licence requirements in binary .debs
 
 More than that, licensing information should be about the binary
 files, not the source files.

I could never figure out how to separate the license of the binary
files from the licenses of the source files used to generate the
binaries in all but trivial cases, so I've avoided drawing
distinctions between the two. I'm also not sure if there's some case
where the distinction actually matters. [If there is, pointing it out
would be useful.]


Don Armstrong

-- 
The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Goals of debian/copyright

[Don Armstrong]

I think we're getting bogged down in the debian/copyright discussion,
and I'm starting to think that some enumeration of what we need
debian/copyright for would help us figure out what it should actually
contain.

I've listed the things that I remember from the relevant threads (and
my personal recollection):

1) DFSG Free licensing of all parts distributed by Debian in main

2) License compatibility (both intra-work and inter-work)

3) Satisfy licence requirements in binary .debs

4) Copyright and licensing status of Debian packaging

5) Kudos/courtesy to authors acknowledging their work

6) Documentation for users about usability of packages in non-free
(IE, non-commercial, non-modifiable, etc.)

If I've missed anything, please tack it in here.

Once we reach some consensus with what the copyright file should
enable us to do, we can start talking about what (if anything) needs
to change regarding the status quo of the copyright file (and possibly
even come to some consensus as to what the status quo actually is.)


Don Armstrong

-- 
UF: What's your favorite coffee blend?
PD: Dark Crude with heavy water. You are understandink? If geiger
counter does not click, the coffee, she is just not thick.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Goals of debian/copyright

[Don Armstrong]

On Tue, 24 Mar 2009, Bill Allombert wrote:

 On Tue, Mar 24, 2009 at 02:56:57PM -0700, Don Armstrong wrote:
  I think we're getting bogged down in the debian/copyright
  discussion, and I'm starting to think that some enumeration of
  what we need debian/copyright for would help us figure out what it
  should actually contain.

  3) Satisfy licence requirements in binary .debs
 
 I'd like to remember that binary .deb files are not required by policy
 to include a copyright file at all, due to 12.3:
 
  `/usr/share/doc/package' may be a symbolic link to another
  directory in `/usr/share/doc' only if the two packages both
  come from the same source and the first package Depends on the
  second.[2]

I'm not really concerned yet with what policy requires; we can change
policy if necessary, after all. Lets first come to agreement with what
we need debian/copyright to do.
 

Don Armstrong

-- 
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
 -- Douglas Adams _The Long Dark Tea-Time of the Soul_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Goals of debian/copyright

[Don Armstrong]

On Wed, 25 Mar 2009, Ben Finney wrote:
 Don Armstrong d...@debian.org writes:
  6) Documentation for users about usability of packages in non-free
  (IE, non-commercial, non-modifiable, etc.)
 
 Why restrict this point to non-free?

Because non-free works don't satisfy the DFSG, and have terms that can
directly affect their usability by users. Figuring out whether you can
actually use a work in non-free is a critical use case for
debian/copyright.

 I think it's important for users of *all* software to have easy,
 predictably-located access to the terms under which they receive it.

What's the use case? That's what I'd like to focus on first; what
debian/copyright needs to enable people to do, not how it enables
people to do it.


Don Armstrong

-- 
Them as can do has to do for them as can't. And someone has to speak
up for them as have no voices.
 -- Grandma Aching in _The Wee Free Men_ by Terry Pratchett p227

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#163666: debian-policy: Unclear result with [arch] and |

[Don Armstrong]

On Sun, 25 Jan 2009, Russ Allbery wrote:
 + If the architecture-restricted dependency is part of a set of
 + alternatives using tt|/tt, that branch of the alternative is
 + ignored completely on architectures that do not match the
 + restriction.  For example:
 + example compact=compact
 +Build-Depends: foo [!i386] | bar [!amd64]
 + /example
 + is equivalent to ttbar/tt on the i386 architecture, to
 + ttfoo/tt on the amd64 architecture, and to ttfoo |
 + bar/tt on all other architectures.

The branch part is slightly confusing; I think you want that
alternative. [Otherwise it makes it sound like foo [!i386] | bar
[!amd64] should be treated like foo on everything not i386 or bar on
everything not i386/amd64; you have to read the example to figure out
exactly what is meant.]


Don Armstrong

-- 
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
 -- Douglas Adams _The Long Dark Tea-Time of the Soul_

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian version numbers and strcmp()

[Don Armstrong]

On Sun, 25 Jan 2009, Roger Leigh wrote:
 Having a canonical implementation of the version comparison in a C
 library would be super, since all the other languages could just
 wrap it.

The implementation I wrote for debbugs is a fallback for when
libapt-pkg-perl isn't around; I think any language that can use a
library would be best off using it, with code that implements the C
verison of the dpkg comparison exactly as a fallback.

We probably do need a libdpkg at some point in time to get rid of this
kind of problem.
 

Don Armstrong

-- 
Tell me something interesting about yourself.
Lie if you have to.
 -- hugh macleod http://www.gapingvoid.com/archives/batch20.php

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian version numbers and strcmp()

[Don Armstrong]

On Thu, 22 Jan 2009, Adeodato Simó wrote:
 I'd like to hear from members of this list what they think about the
 following issue: I just noticed that to determine whether two Debian
 versions are equal, one can't use strcmp() or similar, and must
 implement the full comparison algorithm. For example, 0.9 and 0.09
 are the same version according to Policy.

[...]

 Is there a reason for it to be this way? Is there a reason that
 would advise against changing it?

If version numbers aren't equal, there must be a greater than or less
than relationship between them. If you think that 0.9 and 0.09 should
not be equal, then a proposal for a rule to make the first greater
than or less than the other is needed. 

In my mind, these are no different than the difference between version
90 and version 090; they're not equal strings, but are certainly equal
version numbers (and equal numbers in general). Just like you can't
compare numbers for equality using strcmp, you can't compare versions
for equality using it either.


Don Armstrong

-- 
The state must declare the child to be the most precious treasure of
the people. As long as the government is perceived as working for the
benefit of the children, the people will happily endure almost any
curtailment of liberty and almost any deprivation.
 -- Adolf Hitler _Mein Kampf_ p403

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509732: closed by Don Armstrong d...@debian.org (Re: Bug#509732: Kalle's message #68)

[Don Armstrong]

On Sun, 28 Dec 2008, José Luis González wrote:
 The bug is about the Manual, not the policy package. The
 debian-policy package wouldn't [make] unrelated software on the
 system (or the whole system) break, only the Manual. If the
 erroneous Manual was not yet in the package that severity wouldn't
 apply to the package. If it was, the severity would apply to the
 Document in the package. The former isn't falling afoul of, the
 latter could.

I have no clue what you're talking about here, then. This hypothetical
case makes no sense.

If it breaks other packages, it's an RC bug. If the bug is in
debian-policy, but doesn't actually break other packages, then it's
(probably) not an RC bug. People are watching -policy and can make the
determination.
 
 May I know if bugs under debian-policy are sent to the list? If they
 are not automatically it is still possible that it won't get into
 the list and won't have its severity properly set.

They are automatically sent.
 
 Please, do not close bugs just because you don't want to deal with
 them.

I closed this bug with that message because:

1) The problem that I could understand was entirely hypothetical

2) The failure class that you presented is already covered

Thus, the problem has already been dealt with.


Don Armstrong

-- 
Sentenced to two years hard labor (for sodomy), Oscar Wilde stood
handcuffed in driving rain waiting for transport to prison.  If this
is the way Queen Victoria treats her prisoners, he remarked, she
doesn't deserve to have any.

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509732: Bug severity and release-critical status (was: Bug#509732: Debian policy doesn't feature RC bugs)

[Don Armstrong]

On Sun, 28 Dec 2008, Stefano Zacchiroli wrote:
 The reason why I'm reporting it here is that such a tool would also
 enable to address needs such as the reported one: wishlist bug
 report, marked with some RC-severity in the override.

If a bug is RC, the RMs have the authority to make it Severity:
serious. If it's not, the RMs can make it important. [If it's not RC
just for this release, the -ignore tag can be used.]

Any other decision about severities is the domain of the maintainer.
[The one exception to the above is that a maintainer can decide that a
package is not fit for release; they can't do the converse.]


Don Armstrong

-- 
Build a fire for a man, an he'll be warm for a day.  Set a man on   
fire, and he'll be warm for the rest of his life.
 -- Jules Bean

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509732: Debian policy doesn't feature RC bugs

[Don Armstrong]

On Sat, 27 Dec 2008, José Luis González wrote:
 On Fri, 26 Dec 2008 19:46:36 -0800
 Don Armstrong d...@debian.org wrote:
  Whether we decide to release with bugs of serverity = serious in
  pseudopackages is a decision for the release managers, and the
  information for them to make that decision can be made available
  to them if it is not already available.
 
 May I know if the BTS is part of that information?

The BTS provides the information as to which bugs have severities
which are defined as release critical. The RMs make the final
decisions as to which bugs *are* release critical, but they record
this decision in the BTS by setting the severities.

 This bug is about the Debian Policy, not about the debian-policy
 package.

They are one and the same. [If you're refering to how Debian actually
operates and does things, wether debian-policy is the appropriate
place to file bugs depends about what you're actually talking about.]


Don Armstrong

-- 
I'd never hurt another living thing.
But if I did...
It would be you.
 -- Chris Bishop  http://www.chrisbishop.com/her/archives/her69.html

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509732: Kalle's message #68

[Don Armstrong]

On Sat, 27 Dec 2008, José Luis González wrote:
 On Fri, 26 Dec 2008 20:11:03 -0800
 Don Armstrong d...@debian.org wrote:
  It should be filed against debian-policy with the appropriate
  severity.
 
 What is the appropriate severity?

Depends on the bug. I can't think of a non-packaging mistake in
debian-policy that would by itself be a RC bug, but I suppose such a
pathological case could be invented.

  That assumes that the people reading the list won't file the
  appropriate bug on the appropriate package. I never known that not
  to be the case.
 
 Can another developer file a serious bug on the debian-policy
 package if the mantainer doesn't?

Of course.

 According to bug-maint-info.txt a severe bug can be filed when it
 violates the Policy or the *mantainer* considers the *package*
 unsuitable for release.

Anyone can file an RC bug. This sentence is talking about the fact
that a maintainer can decide that a package is unsuitable for release
in addition to all of the other things that can make a package
unsuitable for release. I should note too that the canonical location
for this documentation is http://bugs.debian.org, *not* doc-debian.
[doc-debian is a convenience copy.]

  and if a package isn't watched by people who know, then the bug
  probably isn't going to seriously affect the release anyway.
 
 This goes against the social contract:

[snip SC §4]

 If it is watched by a user he can't file a RC bug.

Users *can* and *do* file RC bugs.[1] My point was that if a bug was
filed at the wrong severity, and no one noticed, then presumably the
package isn't popular enough for enough people to care about it to set
the severities appropriately.
 
Here, the fundamental problem appears to be a misunderstanding of who
can alter severities (anyone) versus who makes the final decision as
to what the severities shall be (maintainers + RMs).


Don Armstrong

1: As an aside, any time one might think that SC §4 is being violated,
before trotting it out on the list, think long and hard about whether
it actually is being violated. Odds are it's not.
-- 
People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide.
 -- John Brown, DEA Chief

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509732: Debian policy doesn't feature RC bugs

[Don Armstrong]

On Thu, 25 Dec 2008, José Luis González wrote:
 If a problem is RC, it should be marked as RC. If the BTS manages
 pseudopackages, a bug in a pseudopackage that is RC should be marked
 as RC in the BTS.

The BTS has nothing to do with deciding whether particular bugs are
release critical or not. We indicate to other tools (like britney) the
set of bugs which are RC and the packages that they affect.

Whether we decide to release with bugs of serverity = serious in
 pseudopackages is a decision for the release managers, and the
information for them to make that decision can be made available to
them if it is not already available.

 I am sorry but debian-policy isn't featured in
 http://www.debian.org/Bugs/pseudo-packages

debian-policy is not a pseudo package. It's a real package that is
released with Debian.
 
 Another bug should be filed on www.debian.org for this.

The documentation describing what to do if you don't know what package
to file a bug against is correct, though patches to make it clearer
are certainly acceptable.


Don Armstrong

-- 
She was alot like starbucks.
IE, generic and expensive.
 -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/001376.html

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509732: Kalle's message #68

[Don Armstrong]

On Fri, 26 Dec 2008, José Luis González wrote:
 If you still don't understand, imagine that a text is mistakenly
 introduced in the Policy and it causes a RC bug. How should this bug
 about the Policy be reported? According to the Policy Manual:

It should be filed against debian-policy with the appropriate
severity.
 
 If the error is reported to the list it can remain and the package
 with the erroneous policy be released if it is included in the
 package and the Policy isn't amended before.

That assumes that the people reading the list won't file the
appropriate bug on the appropriate package. I never known that not to
be the case.

 If the error is reported to the Bug Tracking System we are in a
 similar case as with the mailing list. Only if a mantainer raises
 severity of the debian-policy *package* to serious would the bug be
 considered as RC.

If the bug is actually RC, someone has to recognize it as such and
raise the severity. This isn't a serious problem for packages such as
-policy which are watched by loads of people, and if a package isn't
watched by people who know, then the bug probably isn't going to
seriously affect the release anyway.


Don Armstrong

-- 
Show me your flowcharts and conceal your tables, and I shall continue
to be mystified. Show me your tables, and I won't usually need your
flowcharts; they'll be obvious.
 -- Fredrick P. Brooks Jr., The Mythical Man Month

http://www.donarmstrong.com  http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Stepping down from Policy team

[Don Armstrong]

On Tue, 23 Dec 2008, Manoj Srivastava wrote:
  Again, I thank all the folks who have been involved in Debian
  technical policy development over the years, I think the technical
  policy is one of the best things about Debian. It has been
  wonderful working with all y'all.

Thanks, Manoj, for your work in helping to keep Debian's Policy
technically rigorous and relatively coherent for as long as you have.
I think quite a few of us share your opinion that policy is one of the
most important things about Debian, and the largely unsung work of you
and Russ, along with all of the other patch submitters and discussion
participants is the only reason that policy has remained in as good a
shape as it has.


Don Armstrong

-- 
I shall require that [a scientific system's] logical form shall be
such that it can be singled out, by means of emperical tests, in a
negative sense: it must be possible for an emperical scientific system
to be refuted by experience.
 -- Sir Karl Popper _Logic of Scientific Discovery_ §6

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#488039: policy: chown uses owner:group not owner.group

[Don Armstrong]

On Thu, 26 Jun 2008, Ian Jackson wrote:
 Kurt Roeckx writes (Bug#488039: policy: chown uses owner:group not 
 owner.group):
  There are several places in policy that use something like root.root,
  when talking about the owner and group of a file.  People used to use
  that notation to separate the owner and group, and it
  still works, but the proper notation would be root:root.
 
 What is wrong with user.group ?  I see that it's not currently
 documented but it has worked forever and I hope it's not going away.

. can potentially be a character in a username or groupname. While
using . has worked for a long time, it should not be advocated in
policy, and portable scripts should not use it.


Don Armstrong

-- 
Sentenced to two years hard labor (for sodomy), Oscar Wilde stood
handcuffed in driving rain waiting for transport to prison.  If this
is the way Queen Victoria treats her prisoners, he remarked, she
doesn't deserve to have any.

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#172436: Is it OK for the new policy wording to be a SHOULD?

[Don Armstrong]

On Mon, 28 Apr 2008, Raphael Hertzog wrote:
 On Mon, 28 Apr 2008, Bas Wijnen wrote:
   This would mean that every program that does not already follow
this directive would instantly turn buggy (conventionally, a violation
of a SHOULD directive is a normal bug)
  
  IMO that's fine.  They're not RC bugs, just things which should be
  fixed.
 
 Bas, it seems you missed the discussion about the fact that Gnome
 has its own way of defining the user's preferred browser. So no,
 it's not clear that this is something that needs to be fixed at the
 Debian level.

It's fine that gnome has it's own way; in the cases where gnome is
running, sensible-browser should still be called, as it obeys the
gnome configuration if BROWSER is not set.[1] This allows gnome to
obey BROWSER if set, and if not, use gnome-www-browser, which should
do the right thing.

BROWSER should override the browser setting for everything, even when
there is a settable setting in gnome's UI.


Don Armstrong

1: At least, it calls gnome-www-browser, which I believe obeys the
gnome configuration.
-- 
Nearly all men can stand adversity, but if you really want to test his
character, give him power.
 -- Abraham Lincoln

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#477990: Remove non-conflicting requirement in optional; relax dependencies

[Don Armstrong]

Package: debian-policy
Version: 3.7.3.0
Severity: wishlist
User: [EMAIL PROTECTED]
UserTags: discussion
Tag: patch

The requirement of optional packages not to conflict with eachother
and not to depend on essential packages are outdated, and appear to
stem from a time where someone would actually want to install all of
optional.

As such, I suggest that this requirement be removed, and only the
meaning of optional packages that you'd want without specialized
requirements kept. The attached patch as an initiation point for
discussion acheives this.


Don Armstrong

-- 
I shall require that [a scientific system's] logical form shall be
such that it can be singled out, by means of emperical tests, in a
negative sense: it must be possible for an emperical scientific system
to be refuted by experience.
 -- Sir Karl Popper _Logic of Scientific Discovery_ §6

http://www.donarmstrong.com  http://rzlab.ucr.edu
diff --git a/policy.sgml b/policy.sgml
index ae7149f..7d5a108 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -718,25 +718,22 @@
 		install if you didn't know what it was and don't have
 		specialized requirements. This is a much larger system
 		and includes the X Window System, a full TeX
-		distribution, and many applications. Note that
-		optional packages should not conflict with each other.
+		distribution, and many applications.
 	/item
 	tagttextra/tt/tag
 	item
-		This contains all packages that conflict with others
-		with required, important, standard or optional
-		priorities, or are only likely to be useful if you
-		already know what they are or have specialized
-		requirements.
+		This contains all packages that are only likely to be
+		useful if you already know what they are or have
+		specialized requirements.
 	/item
 	  /taglist
 	/p
 
 	p
-	  Packages must not depend on packages with lower priority
-	  values (excluding build-time dependencies).  In order to
-	  ensure this, the priorities of one or more packages may need
-	  to be adjusted.
+	  Packages with prority required, important, or standard must
+	  not depend on packages with lower priority values (excluding
+	  build-time dependencies). In order to ensure this, the
+	  priorities of one or more packages may need to be adjusted.
 	/p
   /sect
 

Bug#477990: Remove non-conflicting requirement in optional; relax dependencies

[Don Armstrong]

On Sat, 26 Apr 2008, Santiago Vila wrote:
 While it made possible to install all of optional, the idea of this
 policy was never that someone install all of optional. The idea was
 that when browsing the package list, a user could actually choose
 *whatever* set (small or big) of optional packages he/she wishes
 without fear of conflicts.

So in the current state, you have packages which should be optional,
save for the fact that they may conflict with other optional packages
(say, for transition purposes) or depend on non-optional packages, but
insead must be demoted to extra.

This makes the idea of browsing only the list of optional packages
fairly useless, because you must also browse the extra set of packages
to get the set of packages that could conceivably be normally
installed.


Don Armstrong

-- 
A Bill of Rights that means what the majority wants it to mean is worthless. 
 -- U.S. Supreme Court Justice Antonin Scalia

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#403391: debian-policy: scripts as configuration files: should vs. must

[Don Armstrong]

On Mon, 17 Mar 2008, Jörg Sommer wrote:
 Russ Allbery schrieb am Sun 16. Mar, 15:01 (-0700):
  Russ Allbery [EMAIL PROTECTED] writes:
  
   Here is the patch that I'm applying.  If anyone objects, yell now.
  
  Actually, looking at this further, I see the Policy was never updated to
  mention the /etc/cron.hourly directory.  I'm fixing that as well.  Here's
  the new combined patch.
  
  --- orig/policy.sgml
  +++ mod/policy.sgml
  @@ -6388,12 +6388,13 @@
  +   treated as configuration files.  In general, any script that
  +   embeds configuration information is de-facto a configuration
  +   file and should be treated as such.
  ^^
 
 Wasn't the initial request that these files /must/ be configuration
 files?

It really can't be, because there are loads of scripts that have
configuration information embedded but either need not be
configuration files because configuring them is done in some other
manner, or have very sensible defaults that only a few eccentrics
would ever want to change (and they can do so using a diversion.)[1]


Don Armstrong

1: Though I agree that scripts such as this should not live in /etc.
-- 
Physics is like sex. Sure, it may give some practical results, but
that's not why we do it.
 -- Richard Feynman

http://www.donarmstrong.com  http://rzlab.ucr.edu

Bug#114920: [PROPOSAL] remove foolish consistency in perl module names

[Don Armstrong]

On Wed, 02 Jan 2008, Julian Mehnle wrote:
 I think that from the final sentence it can be inferred that it primarily 
 intends to mandate the _binary_ package name.  So while we're discussing 
 the binary package naming, maybe we can decide whether the mandate should 
 be extended to the _source_ package name as well while we're at it, and 
 clarify the Perl policy to explicitly state whether or not the source 
 package name is covered by the policy's recommendation.

Unless there's a compelling reason to the contrary, a source package
should in general build at least one binary package of the same name.
This is definetly the case when the source package only builds one
binary package.

The reasons why you want to do this is because everyone knows what the
binary package name is, but it's sometimes difficult to map to a
source package, and it prevents the insanity of Source: foo building
Binary: bar, and Source: bar buildling Binary: foo. (Yes, there is at
least one set of packages in the archive that does this.)
 

Don Armstrong

-- 
If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
 -- Friedrich Nietzsche

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#114920: [PROPOSAL] remove foolish consistency in perl module names

[Don Armstrong]

On Wed, 02 Jan 2008, Steve Langasek wrote:
 On Wed, Jan 02, 2008 at 03:46:02PM -0800, Don Armstrong wrote:
  Unless there's a compelling reason to the contrary, a source
  package should in general build at least one binary package of the
  same name. This is definetly the case when the source package only
  builds one binary package.
 
 Not that this is applicable to perl packages, but one very common
 reason for this to not be the case is that the package is a
 library... In that case, it's beneficial to have continuity of the
 source package name whereas the binary package name will change
 periodically.

Right; that's exactly the major compelling reason that I was thinking
about when I wrote the above.


Don Armstrong

-- 
There is no such thing as social gambling. Either you are there to
cut the other bloke's heart out and eat it--or you're a sucker. If you
don't like this choice--don't gamble.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#114920: [PROPOSAL] remove foolish consistency in perl module names

[Don Armstrong]

On Thu, 03 Jan 2008, Julian Mehnle wrote:
 According to a simple survey of the packages in Lenny/amd64 (main,
 contrib, non-free), 2365 of the 11757 source packages (20%!) have no
 binary package of the same name. 814 of these (7% of all) have only
 a single binary package. Wanna mass-file bugs?

No, because changing the source package name is worse than having a
stupid source package name. [The complications that it makes for bug
tracking is the major reason why changing source package names should
not be done unless required.]

 Or maybe the reason doesn't have to be all that compelling.

The reason should be compelling. While it's unfortunate that stupid
source package names have been chosen on initial uploads in the past,
I'm more concerned about the choice of source package names going
forward.


Don Armstrong

-- 
He no longer wished to be dead. At the same time, it cannot be said
that he was glad to be alive. But at least he did not resent it. He
was alive, and the stubbornness of this fact had little by little
begun to fascinate him -- as if he had managed to outlive himself, as
if he were somehow living a posthumous life.
 -- Paul Auster _City of Glass_

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: The policy process and user categories

[Don Armstrong]

On Sun, 30 Dec 2007, Russ Allbery wrote:
 Raphael Hertzog [EMAIL PROTECTED] writes:
  On Mon, 24 Dec 2007, Manoj Srivastava wrote:
 
  I have since used that framework, and I am proposing expanding
   the user tags and using the user debian-policy@lists.debian.org as the
   default user.   I have expanded on the scheme used by Russ, to better
 
  I suggest [EMAIL PROTECTED] as user. That way, the usertags
  are visible on the default view of the bug page.
 
 I had thought that the way this worked was that the usertag address should
 match the maintainer.  Did I get that wrong?

Nah, it's [EMAIL PROTECTED]
 
 Unfortunately, usertags seem to be almost entirely undocumented. I
 mostly figured out how to use them by experimenting and finding
 random blog posts.

Yeah; I need (or preferably, someone else needs) to document it.


Don Armstrong

-- 
Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#432564: Allow debian/rules to not be a makefile

[Don Armstrong]

On Tue, 17 Jul 2007, Manoj Srivastava wrote:
 On Tue, 10 Jul 2007 13:42:03 -0700, Don Armstrong [EMAIL PROTECTED] said: 
  Regardless, even requiring debian/rules to be a makefile doesn't
  actually do much, because someone could do something like:
 
  .DEFAULT:
debian/irule $@
 
  or whatever.
 
 I actually see this as a argument for not changing the rule,
 since using a Makefile does not in any way add restrictions for the
 developer.  debian/rules has been a makefile forever, allowing it to be
 anything else doesn't buy anything practical, just a little geek value
 for useless packages like shoop.

I don't have a problem with requiring that debian/rules be a makefile;
what I'm concerned about are any assumptions about what debian/rules
actually contains besides it being a valid makefile.


Don Armstrong

-- 
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities.
 -- W. Churchill

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#432564: Allow debian/rules to not be a makefile

[Don Armstrong]

On Tue, 10 Jul 2007, Russ Allbery wrote:
 I also could have sworn that we recently tightened this requirement,
 but I can find no mention of that in changelog with some quick
 searches. Am I just imagining things?

It was tightened about 2 or 3 years ago, iirc.

Regardless, even requiring debian/rules to be a makefile doesn't
actually do much, because someone could do something like: 

.DEFAULT: 
  debian/irule $@

or whatever.

People should be using make, but if they have a valid reason for doing
something else, policy shouldn't get in the way.


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#241333: policy mentions that changelogs should be utf-8; this is a bug

[Don Armstrong]

On Wed, 04 Jul 2007, Russ Allbery wrote:
 Comments?

Pretty much all of the tools that read debian/control assume that it
is in UTF-8, including the BTS, so even though it isn't a mandate of
policy, it's effectively mandated by the tools that actually use these
files.
 
 Also, while we're looking at this, where are we on UTF-8 support in
 debian/control?  Is it now time to similarly require that all control
 files be encoded in UTF-8?  There are only 11 packages in the archive with
 non-UTF-8 control files.

Likewise for control.


Don Armstrong

-- 
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities.
 -- W. Churchill

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#241333: policy mentions that changelogs should be utf-8; this is a bug

[Don Armstrong]

On Wed, 04 Jul 2007, Russ Allbery wrote:
 Don Armstrong [EMAIL PROTECTED] writes:
  Pretty much all of the tools that read debian/control assume that it is
  in UTF-8, including the BTS, so even though it isn't a mandate of
  policy, it's effectively mandated by the tools that actually use these
  files.
 
 I assume you mean debian/changelog here.

Right.


Don Armstrong
  
-- 
I'd sign up in a hot second for any cellular company whose motto was:
We're less horrible than a root canal with a cold chisel.
 -- Cory Doctorow

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Range Voting - the simpler better alternative to Condorcet voting

[Don Armstrong]

On Sat, 19 May 2007, CLAY S wrote:
 My name is Clay Shentrup and I am an Ubuntu user - so I have much respect
 for your endeavors and your hard work on them.  I write to discuss a simple
 improvement that could be had with your elections, merely by changing to a
 better and simpler voting method: Range Voting.

Warren Smith's copious arguments to the contrary, it's not entirely
clear that Range Voting is superior to or even simpler than
concordecet voting.
 
 Dr. Smith also has done some analysis of Debian's elections, which represent
 a wonderful dataset for scientific study.
 http://rangevoting.org/Debian2003.html

His analysis is rather scanty, unfortunatly, and fails to provide any
real reasoning why we should even consider switching to Range Voting,
especially as the conversion from the balots cast to RV balots is
entirely arbitrary.

Finally, if you are really interested in even being able to test RV in
Debian, you need to actually write the code to implement RV in
devotee.


Don Armstrong

-- 
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
 -- Douglas Adams _The Long Dark Tea-Time of the Soul_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: deluser on purge (was: Piuparts testing status update)

[Don Armstrong]

On Tue, 14 Nov 2006, Russ Allbery wrote:
 This is something that I'd really like to see us sort out in policy,
 since I think we should be able to describe consistent behavior with
 regard to system users and package purging to our users.

What makes the most sense to me is to not delete the user, and warn
that this has not been done. (I'm really not sure how best to do the
warning besides outputing to STDERR.)

This avoids the obvious problems with deleting a user who may still
own files on the system, and then recreating a different username for
a different program with the same uid which shouldn't have access to
those files (or, worse, if someone was insane and made something
setuid to the autogenerated uid.)

A further refinement of this suggestion is to allow/suggest prompting
using debconf with a low priority question to remove the user, with
the default set to not delete. [This would be my personal preference;
it may even be worthwhile to consider codifying a best practice,[1]
and then if Joey Hess agrees, creating a dh_installuser or similar
script which implements it, including debconf routines.]

This would allow individuals who knew that they wanted to delete the
user to easily cause the user to be deleted, and do so in an automated
fashion.


Don Armstrong

1: Granted, this best practice should probaly be codified in the
Developer's Reference, not policy, but we could discuss it at the same
time.
-- 
It was said that life was cheap in Ankh-Morpork. This was, of course,
completely wrong. Life was often very expensive; you could get death
for free.
 -- Terry Pratchet _Pyramids_ p25

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#392362: [PROPOSAL] Add should not embed code from other packages

[Don Armstrong]

On Mon, 16 Oct 2006, Chris Waters wrote:
 Should not says that it's always a bug--just not an RC bug. I'm
 saying that perhaps sometimes it's not a bug. Although I strongly
 agree that it should _usually_ be a bug.

I really can't imagine when it would not be a bug; in some cases, it
may just be a wishlist or minor bug because the libraries don't expose
the proper interfaces or need to be modified before being compiled. In
either case, the proper solution is to eventually fix the interfaces
or library so the extra code can be jettisoned.


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#392362: [PROPOSAL] Add should not embed code from other packages

[Don Armstrong]

On Wed, 11 Oct 2006, Bill Allombert wrote:
 I am not sure we can realistically add a requirement higher than:
 
  A package should not link against copy of libraries packaged
  separately by Debian. 

Any needless code duplication is bad, be it in libraries, perl or
python modules, or even things like documentation. I don't have a
better suggestion for verbiage at this point, but packages should not
be duplicating code that is present in other packages, especially when
already established mechanisms are in place to utilize that code
without duplication. [Actually having the code duplicated in the
upstream source may not be so bad, but it definetly should not be used
to build the binary package.]

Of course, it's true that this would be a should directive; things
that fail to meet it are buggy, but it's not an RC bug.


Don Armstrong

-- 
Clint why the hell does kernel-source-2.6.3 depend on xfree86-common?
infinity It... Doesn't?
Clint good point

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Policy about messages for init scripts

[Don Armstrong]

On Sun, 10 Sep 2006, Mario Iseli wrote:
 Someone makes asterisks around the messages, the other one makes
 rhombuses. So this is my problem, when someone would have 10 of
 those packages installed he would get ugly messages :-)

What people should be doing instead is using lsb-base and
lsb-init-functions' log_failure_message and other functions from there
instead of writing their own custom methods of dealing with it.

Suggest changing init scripts to use lsb-init-functions if you run
across those that do not.
 

Don Armstrong

-- 
It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead
bodies. Do you think I want to have an academic debate on this
subject?
 -- Robert Fisk

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Date and Upsteam-URL fields

[Don Armstrong]

On Thu, 08 Jun 2006, Kai Hendry wrote:
 One being Date:
 
 To show when the package was last touched. Currently I get this
 information from the painfully from the Latest News section of the QA
 page, e.g.: http://packages.qa.debian.org/g/geomview.html

Is there any reason why

zcat /usr/share/doc/package/changelog.Debian.gz |perl -ne \
'next unless /^ -- .+?\s{2}(.+)$/; print $1,qq(\n) and exit;';

isn't sufficient for all non-native packages?
 
 Next field is URL: or URI: (http://www.w3.org/Addressing/)
 Or perhaps Upsteam-URL: 
 
 A reference to upstream's homepage.

That should be in /usr/share/doc/package/copyright; some packages
also have it in the description.


Don Armstrong

-- 
DIE!
 -- Maritza Campos http://www.crfh.net/d/20020601.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Date and Upsteam-URL fields

[Don Armstrong]

On Thu, 08 Jun 2006, Kai Hendry wrote:
 On 2006-06-08T00:31-0700 Don Armstrong wrote:
  Is there any reason why
  zcat /usr/share/doc/package/changelog.Debian.gz |perl -ne \
  'next unless /^ -- .+?\s{2}(.+)$/; print $1,qq(\n) and exit;';
  isn't sufficient for all non-native packages?
 
 What if that package isn't installed on your system?

Then, FE:

wget -O- -q 
http://packages.debian.org/changelogs/pool/main/a/apache2/current/changelog.txt 
|
 perl -ne 'next unless /^ -- .+?\s{2}(.+)$/; print $1,qq(\n) and exit;';
 
 It's all also uglier than apt-cache show package | grep ^Date:

Possibly, but what you're proposing duplicates the information that
already exists; this seems to me to be rather suboptimal. [And it's
fairly trivial to hide the above behind some sort of nice frontend.]
 
   Next field is URL: or URI: (http://www.w3.org/Addressing/)
   Or perhaps Upsteam-URL: 
   A reference to upstream's homepage.
  That should be in /usr/share/doc/package/copyright; some packages
  also have it in the description.
 
 Sure, but lets make it a little more concrete.
 
 Upstream: http://... 
 is probably sufficient after thinking about it.

You might as well start by looking for something like that, then just
fall back upon anything that looks like a URL if there's no indication
which url is the specific upstream location; putting this into the
control file doesn't really make all that much sense to me, since when
it actually matters, watch files are much more useful and even allow
automated processing which is probably what you want anyway.


Don Armstrong

-- 
The attackers hadn't simply robbed the bank. They had carried off
everything portable, including the security cameras, the carpets, the
chairs, and the light and plumbing fixtures. The conspirators had
deliberately punished the bank, for reasons best known to themselves,
or to their unknown controllers. They had superglued doors and
shattered windows, severed power and communications cables, poured
stinking toxins into the wallspaces, and concreted all of the sinks
and drains. In eight minutes, sixty people had ruined the building so
thouroughly that it had to be condemed and later demolished.
 -- Bruce Sterling, _Distraction_ p4

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#355263: RFC/RFS: beef - a flexible BrainFuck interpreter

[Don Armstrong]

On Sat, 04 Mar 2006, Bas Wijnen wrote:
 On Fri, Mar 03, 2006 at 11:41:59PM +0100, Andrea Bolognani wrote:
   * W: The program is licensed under GPL version 2.
  
  Will not fix. From the Policy, section 12.5:
  
  Packages distributed under the UCB BSD license, the Artistic license,
  the GNU GPL, and the GNU LGPL should refer to the files
  /usr/share/common-licenses/BSD,
  /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL, and
  /usr/share/common-licenses/LGPL respectively
  
  So /usr/share/common-licenses/GPL is the right file to point to.

./src/tape_new_cell.c This program is free software; you can redistribute 
it and/or
./src/tape_new_cell.c modify it under the terms of the GNU General Public 
License as
./src/tape_new_cell.c published by the Free Software Foundation; either 
version 2 of
./src/tape_new_cell.c the License, or (at your option) any later version.

[From beef]
 
 Perhaps Policy needs an upgrade here... It seems logical to me that
 you must always point to the license which is used. In case of GPL
 version 2 or later, that is usually understood as the latest
 version of the GPL (although of course the user may choose to use
 an earlier version, as long as it's at least version 2).

Yes, that's what you should do. In the instant case, because the
program is licenced under 2 or later, the right thing to do is to
point at the GPL symlink.


Don Armstrong

-- 
The attackers hadn't simply robbed the bank. They had carried off
everything portable, including the security cameras, the carpets, the
chairs, and the light and plumbing fixtures. The conspirators had
deliberately punished the bank, for reasons best known to themselves,
or to their unknown controllers. They had superglued doors and
shattered windows, severed power and communications cables, poured
stinking toxins into the wallspaces, and concreted all of the sinks
and drains. In eight minutes, sixty people had ruined the building so
thouroughly that it had to be condemed and later demolished.
 -- Bruce Sterling, _Distraction_ p4

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: What do you win by moving things to non-free?

[Don Armstrong]

[Can we *PLEASE* move this conversation to an appropriate list, like
-project? MFT: set appropriately, and Cc:'ed for good measure.]

On Sat, 16 Apr 2005, Adrian Bunk wrote:
 On Sat, Apr 16, 2005 at 09:07:58AM +1000, Matthew Palmer wrote:
  But why can people only use documentation if it's in Debian main?
 
 Let me try to explain it:
 
 We agree that there's several software where not DFSG-free
 documentation [1] is required for many usages of the software.

Probably not required, since the documentation isn't a Depends: of the
package, merely a Recommends: or Suggests:. [Let's s/required/useful/
and continue.]

 Unless I want to search and use the upstream documentation locations
 of every affected software I use, I have to add non-free to my
 sources.list and take care that I install the now separate
 documentation packages for all software I use.

In almost all cases the documentation is already separated... but lets
continue on anyway.

 The second point might only be a minor nuisance for me, but the
 first one will tell me that Debian would be much less usable if I
 wouldn't use non-free.

So you're objecting to the fact that the non-free documentation is
going to be present in the non-free part of the ftp archive? Fine. You
have my permission to call the non-free part of the ftp archive
freedom impaired. Does that help?[1]

Or is it that you want Debian to ship the non-free documentation in
main so you can close your eyes to the fact that the documentation is
not free?

 If Debian continues to get much Debian anyway considers everything
 non-free reputation for being more fundamentalistic than even RMS,
 less external people will seriously consider comments of Debian on
 licence problems.

So we should not worry at all about licensing issues? How would Qt
have been relicensed then?[2][3]

 What do you win by moving things to non-free?

We make the separation between which works are free, and which works
are not free quite clear and distinct. That's it. Surely it's more
logical to do that than to ship non-free works in main?


Don Armstrong

1: Hell, I'll even set up a redirect alias that points to an
appropriate mirror of the non-free package list if this is a major
sticking point.

2: Astute observers will note that the incompatibility of the QPL with
the GPL and the DFSG may be partially Debian's fault.

3: As a final note, it's not like any of the license deliberations
have been reached in vacuo or in camera. If anyone feels that specific
errors have been made in -legal's determination of a license's status,
please, please, read the appropriate list archives where the license
has been discussed, and point out the errors. Even though everyone on
-legal tries to do a thorough, fair, and impartial job, mistakes are
made from time to time.
-- 
Build a fire for a man, an he'll be warm for a day.  Set a man on   
fire, and he'll be warm for the rest of his life.
 -- Jules Bean

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]