Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-08-04 Thread Russ Allbery
Guillem Jover <[EMAIL PROTECTED]> writes:

> Seconded.

Thanks!  That's two seconds, so I've committed this patch for the next
Policy release.

-- 
Russ Allbery ([EMAIL PROTECTED])   



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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-08-04 Thread Guillem Jover
Hi,

On Sat, 2008-07-05 at 13:50:29 -0700, Russ Allbery wrote:
> Here's a proposed clarification of the current Policy language around
> Essential.  Comments, feedback, seconds?

> diff --git a/policy.sgml b/policy.sgml
> index c9bd84f..d0dc2dc 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -985,29 +985,23 @@
> (see below), and should not do so unless they depend on a
> particular version of that package.
>  
> -  Essential is defined as the minimal set of functionality
> -  that must be available and usable on the system even
> -  when packages are in an unconfigured (but unpacked)
> -  state.  This is needed to avoid unresolvable dependency
> -  loops on upgrade.  If packages add unnecessary
> -  dependencies on packages in this set, the chances that
> -  there will be an unresolvable
> -  dependency loop caused by forcing these Essential
> -  packages to be configured first before they need to be
> -  is greatly increased.  It also increases the chances
> -  that frontends will be unable to
> -  calculate an upgrade path, even if one
> -  exists.
> +   Essential is needed in part to avoid unresolvable dependency
> +   loops on upgrade.  If packages add unnecessary dependencies
> +   on packages in this set, the chances that there
> +   will be an unresolvable dependency loop
> +   caused by forcing these Essential packages to be configured
> +   first before they need to be is greatly increased.  It also
> +   increases the chances that frontends will be unable to
> +   calculate an upgrade path, even if one
> +   exists.
>  
>  
> -  Also, it's pretty unlikely that functionality from
> -  Essential shall ever be removed (which is one reason why
> -  care must be taken before adding to the Essential
> -  packages set), but packages have been removed
> -  from the Essential set when the functionality moved to a
> -  different package. So depending on these packages
> -  just in case they stop being essential does way
> -  more harm than good.
> +   Also, functionality is rarely ever removed from the
> +   Essential set, but packages have been removed from
> +   the Essential set when the functionality moved to a
> +   different package. So depending on these packages just
> +   in case they stop being essential does way more harm
> +   than good.
>  
>
>   
> @@ -1094,10 +1088,13 @@
>   Essential packages
>  
>   
> -   Some packages are tagged essential for a system
> -   using the Essential control file field.
> -   The format of the Essential control field is
> -   described in .
> +   Essential is defined as the minimal set of functionality that
> +   must be available and usable on the system at all times, even
> +   when packages are in an unconfigured (but unpacked) state.
> +   Packages are tagged essential for a system using the
> +   Essential control file field.  The format of the
> +   Essential control field is described in  +   id="f-Essential">.
>   
>  
>   
> @@ -1122,6 +1119,19 @@
>   
>  
>   
> +   Maintainers should take great care in adding any programs,
> +   interfaces, or functionality to essential packages.
> +   Packages may assume that functionality provided by
> +   essential packages is always available without
> +   declaring explicit dependencies, which means that removing
> +   functionality from the Essential set is very difficult and is
> +   almost never done.  Any capability added to an
> +   essential package therefore creates an obligation to
> +   support that capability as part of the Essential set in
> +   perpetuity.
> + 
> +
> + 
> You must not tag any packages essential before
> this has been discussed on the debian-devel
> mailing list and a consensus about doing that has been

Seconded.

regards,
guillem


signature.asc
Description: Digital signature


Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-08-04 Thread Jörg Sommer
Hello Russ,

Russ Allbery schrieb am Sat 05. Jul, 13:50 (-0700):
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 
> > I think we can add wording that says that these criteria are
> >  useful while trying to decide whether a package should be made
> >  Essential or not.  Once it is Essential, then all bets are off, and
> >  packages are, in effect, never removed from the set, unless
> >  extraordinary effort is undertaken by someone.
> 
> Here's a proposed clarification of the current Policy language around
> Essential.  Comments, feedback, seconds?
> 
> The first part of the diff cuts out of the footnote some things that are
> moved into the main Policy text in the second part of the diff.
> 
> diff --git a/policy.sgml b/policy.sgml
> index c9bd84f..d0dc2dc 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -985,29 +985,23 @@

Sounds good. I second this patch.

Bye, Jörg.
-- 
Prof. in der Mathematikvorlesung zu einem vergessenen φ in der
Gleichung: „Klein‐φ macht auch Mist.“


signature.asc
Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP


Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-07-05 Thread Russ Allbery
Manoj Srivastava <[EMAIL PROTECTED]> writes:

> I think we can add wording that says that these criteria are
>  useful while trying to decide whether a package should be made
>  Essential or not.  Once it is Essential, then all bets are off, and
>  packages are, in effect, never removed from the set, unless
>  extraordinary effort is undertaken by someone.

Here's a proposed clarification of the current Policy language around
Essential.  Comments, feedback, seconds?

The first part of the diff cuts out of the footnote some things that are
moved into the main Policy text in the second part of the diff.

diff --git a/policy.sgml b/policy.sgml
index c9bd84f..d0dc2dc 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -985,29 +985,23 @@
  (see below), and should not do so unless they depend on a
  particular version of that package.
 
-  Essential is defined as the minimal set of functionality
-  that must be available and usable on the system even
-  when packages are in an unconfigured (but unpacked)
-  state.  This is needed to avoid unresolvable dependency
-  loops on upgrade.  If packages add unnecessary
-  dependencies on packages in this set, the chances that
-  there will be an unresolvable
-  dependency loop caused by forcing these Essential
-  packages to be configured first before they need to be
-  is greatly increased.  It also increases the chances
-  that frontends will be unable to
-  calculate an upgrade path, even if one
-  exists.
+ Essential is needed in part to avoid unresolvable dependency
+ loops on upgrade.  If packages add unnecessary dependencies
+ on packages in this set, the chances that there
+ will be an unresolvable dependency loop
+ caused by forcing these Essential packages to be configured
+ first before they need to be is greatly increased.  It also
+ increases the chances that frontends will be unable to
+ calculate an upgrade path, even if one
+ exists.
 
 
-  Also, it's pretty unlikely that functionality from
-  Essential shall ever be removed (which is one reason why
-  care must be taken before adding to the Essential
-  packages set), but packages have been removed
-  from the Essential set when the functionality moved to a
-  different package. So depending on these packages
-  just in case they stop being essential does way
-  more harm than good.
+ Also, functionality is rarely ever removed from the
+ Essential set, but packages have been removed from
+ the Essential set when the functionality moved to a
+ different package. So depending on these packages just
+ in case they stop being essential does way more harm
+ than good.
 
   

@@ -1094,10 +1088,13 @@
Essential packages
 

- Some packages are tagged essential for a system
- using the Essential control file field.
- The format of the Essential control field is
- described in .
+ Essential is defined as the minimal set of functionality that
+ must be available and usable on the system at all times, even
+ when packages are in an unconfigured (but unpacked) state.
+ Packages are tagged essential for a system using the
+ Essential control file field.  The format of the
+ Essential control field is described in .

 

@@ -1122,6 +1119,19 @@

 

+ Maintainers should take great care in adding any programs,
+ interfaces, or functionality to essential packages.
+ Packages may assume that functionality provided by
+ essential packages is always available without
+ declaring explicit dependencies, which means that removing
+ functionality from the Essential set is very difficult and is
+ almost never done.  Any capability added to an
+ essential package therefore creates an obligation to
+ support that capability as part of the Essential set in
+ perpetuity.
+   
+
+   
  You must not tag any packages essential before
  this has been discussed on the debian-devel
  mailing list and a consensus about doing that has been

-- 
Russ Allbery ([EMAIL PROTECTED])   



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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-06 Thread Manoj Srivastava
On Thu, 05 Jun 2008 21:40:04 +0200, Giacomo Catenazzi <[EMAIL PROTECTED]> said: 

> Steve Langasek wrote:
>> On Thu, Jun 05, 2008 at 06:25:14PM +0200, Giacomo A. Catenazzi wrote:
>>> Manoj Srivastava wrote:
 Hi, On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg
 <[EMAIL PROTECTED]> said:
>> 
> Policy section 3.8, about essential packages, doesn't explain
> when/why essential is neccessary, only that it should not be
> essential if it's not necessary.
>> 
 My understanding is that a package is Essential if without it is
 impossible to install any more packages to the system -- that is,
 the package is required for proper functioning of dpkg. If my
 understanding is correct, it should be easy to add in a line about
 when packages can be made Essential.
>> 
>>> In addition "Essential" is also used not full dependencies with
>>> "obvious" packages. (Policy 3.5)
>> 
>> This is not part of the rationale for a package's inclusion in
>> Essential, it's an effect of a package's inclusion in Essential.
>> 
>> Packages should only be in the Essential set if they have to be there
>> to guarantee the operation of dpkg.

> I'm not so sure.  Or better, I agree the first paragraph (a package
> will become "Essential" if it is need by dpkg), but I really think
> that the second part it is wrong:

> I don't think we should remove "easily" the essential status from a
> package.  Packages expect essential package to be installed, without
> requiring dependencies, so a lot of package will broke on removal of
> some essential.

I think we can add wording that says that these criteria are
 useful while trying to decide whether a package should be made
 Essential or not.  Once it is Essential, then all bets are off, and
 packages are, in effect, never removed from the set, unless
 extraordinary effort is undertaken by someone.

> I think policy should include a incomplete list of "essential"
> package, because of the "side effect" (no dependencies on essential
> package).

No, this decision should remain with the ftp-masters, not hard
 coded into policy.

manoj
-- 
"Not Hercules could have knock'd out his brains, for he had none."
Shakespeare
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-06 Thread Manoj Srivastava
On Fri, 6 Jun 2008 09:38:15 +0200, Bernhard R Link <[EMAIL PROTECTED]> said: 

> * Steve Langasek <[EMAIL PROTECTED]> [080605 19:04]:
>> This is not part of the rationale for a package's inclusion in
>> Essential, it's an effect of a package's inclusion in Essential.
>> 
>> Packages should only be in the Essential set if they have to be there
>> to guarantee the operation of dpkg.

> I've experimented recently with some more minimal build chroots (even
> dropping some essential stuff), and I do not think that above matches
> the current situation.

I think I still stand by what I said:
>>> My understanding is that a package is Essential if without it is
>>> impossible to install any more packages to the system -- that is,
>>> the  package is required for proper functioning of dpkg
on the system.

This remains true, if one is talking of a system, instead of
 part of one hosted on another system providing most of the services. So
 minimal chroots are out, when deciding whether a Package is Essential
 or not.

manoj
-- 
You will be aided greatly by a person whom you thought to be
unimportant.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



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



Re: Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-06 Thread Bernhard R. Link
* Steve Langasek <[EMAIL PROTECTED]> [080605 19:04]:
> This is not part of the rationale for a package's inclusion in Essential,
> it's an effect of a package's inclusion in Essential.
>
> Packages should only be in the Essential set if they have to be there to
> guarantee the operation of dpkg.

I've experimented recently with some more minimal build chroots (even
dropping some essential stuff), and I do not think that above matches
the current situation.

I think currently it is more of "if they have to be there to garantee
a working system".

Things like passws, sysvinit, mount, e2fsprogs, sysvinit-utils,
libpam-modules or login are as far as I can tell not needed at all
to have dpkg functionally, but as far as I can guess are only essential
because removing them would bring a non-chroot system easily in an
unusable state.

(Surprisingly many things even still work without util-linux, though
splitting it into a mkfs*/fsck* part (which needs the libuuid1
dependency which again pulls in passwd, which again pulls in more stuff)
in an extra package seems a more sensible choice if things were to change
in a way to allow more minimal build chroots).

Hochachtungsvoll,
Bernhard R. Link


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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-05 Thread Giacomo Catenazzi
Steve Langasek wrote:
> On Thu, Jun 05, 2008 at 06:25:14PM +0200, Giacomo A. Catenazzi wrote:
>> Manoj Srivastava wrote:
>>> Hi,
>>> On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg <[EMAIL PROTECTED]>
>>> said:
>
 Policy section 3.8, about essential packages, doesn't explain when/why
 essential is neccessary, only that it should not be essential if it's
 not necessary.
>
>>> My understanding is that a package is Essential if without it is
>>>  impossible to install any more packages to the system -- that is, the
>>>  package is required for proper functioning of dpkg. If my understanding
>>>  is correct, it should be easy to add in a line about when packages can
>>>  be made Essential.
>
>> In addition "Essential" is also used not full dependencies with
>> "obvious" packages. (Policy 3.5)
>
> This is not part of the rationale for a package's inclusion in Essential,
> it's an effect of a package's inclusion in Essential.
>
> Packages should only be in the Essential set if they have to be there to
> guarantee the operation of dpkg.

I'm not so sure.
Or better, I agree the first paragraph
(a package will become "Essential" if it is need by dpkg),
but I really think that the second part it is wrong:

I don't think we should remove "easily" the
essential status from a package.
Packages expect essential package to be installed,
without requiring dependencies, so a lot of package
will broke on removal of some essential.

I think policy should include a incomplete list of
"essential" package, because of the "side effect"
(no dependencies on essential package).

ciao
cate


Note:

>From Klecker ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=50832 ):
[1] Essential means that the package does not need to be depended on
(essential does not seem to be guaranteed to work for implicit
Pre-Depends), however the thing that bash provides that is "essential" is
/bin/sh.
(...)





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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-05 Thread Steve Langasek
On Thu, Jun 05, 2008 at 06:25:14PM +0200, Giacomo A. Catenazzi wrote:
> Manoj Srivastava wrote:
>> Hi,
>> On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg <[EMAIL PROTECTED]>
>> said:

>>> Policy section 3.8, about essential packages, doesn't explain when/why
>>> essential is neccessary, only that it should not be essential if it's
>>> not necessary.

>> My understanding is that a package is Essential if without it is
>>  impossible to install any more packages to the system -- that is, the
>>  package is required for proper functioning of dpkg. If my understanding
>>  is correct, it should be easy to add in a line about when packages can
>>  be made Essential.

> In addition "Essential" is also used not full dependencies with
> "obvious" packages. (Policy 3.5)

This is not part of the rationale for a package's inclusion in Essential,
it's an effect of a package's inclusion in Essential.

Packages should only be in the Essential set if they have to be there to
guarantee the operation of dpkg.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]



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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-05 Thread Giacomo A. Catenazzi

Manoj Srivastava wrote:

Hi,
On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg <[EMAIL PROTECTED]>
said:


Policy section 3.8, about essential packages, doesn't explain when/why
essential is neccessary, only that it should not be essential if it's
not necessary.


My understanding is that a package is Essential if without it is
 impossible to install any more packages to the system -- that is, the
 package is required for proper functioning of dpkg. If my understanding
 is correct, it should be easy to add in a line about when packages can
 be made Essential.


In addition "Essential" is also used not full dependencies with
"obvious" packages. (Policy 3.5)

Ah... the rationale is in footnote 7
http://www.us.debian.org/doc/debian-policy/footnotes.html#f7,
which is linked in 3.5.
I think we should split the rationale and put the first part in
3.8. And 3.5 should linke to the section 3.8

ciao
cate





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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-06-05 Thread Manoj Srivastava
Hi,
On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg <[EMAIL PROTECTED]>
said:  

> Policy section 3.8, about essential packages, doesn't explain when/why
> essential is neccessary, only that it should not be essential if it's
> not necessary.

My understanding is that a package is Essential if without it is
 impossible to install any more packages to the system -- that is, the
 package is required for proper functioning of dpkg. If my understanding
 is correct, it should be easy to add in a line about when packages can
 be made Essential.

manoj
-- 
Your own qualities will help prevent your advancement in the world.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



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



Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

2008-05-02 Thread Carl Fürstenberg
Package: debian-policy
Version: 3.7.3.0
Severity: normal

Policy section 3.8, about essential packages, doesn't explain when/why 
essential is neccessary, only that it should not be essential 
if it's not necessary.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information



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