Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system

[Anton Zinoviev]

On 16.V.2001 at 22:43 Joey Hess wrote:
> +
> + 
> +   You should not tag any packages as belonging to a task before 
> +   this has been discussed on the `debian-devel' mailing list and 
> + a consensus about doing that has been reached.
> + 

A consensus is not always possible.  Some resolution mechanism is needed
in case that there is no consensus.

For example what display manager we will choose: gdm, kdm, wdm or xdm?
Maybe gdm, because it provides session menu, but it looks to me a little
buggy.  I'm giving this only as an example.  Surely there will be
conflicts.

Moreover, too many packages have to use the Task field.  Do you want a
discution for all of them in debian-devel? Is the override mechanism
suposed to be only a temporary solution?

A maintainer can and may not be aware of the needs of some task.  An
example: why the maintainer of recode should know that some of the
filters of magicfilter needs recode and that magicfilter belongs to the
task printing?

(Actually I have wrote that again only as an example.  If you want I
will make ITP of meta-magicfilter, meta-apsfilter and maybe meta-cups.
Then one of these three metapackages will belong to the task `Printing'.
Or maybe it is better to have more than one task for printing?)


Anton Zinoviev, [EMAIL PROTECTED]

Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system

[Thomas Bushnell, BSG]

Anton Zinoviev <[EMAIL PROTECTED]> writes:

> For example what display manager we will choose: gdm, kdm, wdm or xdm?
> Maybe gdm, because it provides session menu, but it looks to me a little
> buggy.  I'm giving this only as an example.  Surely there will be
> conflicts.

What does it mean that gdm "looks to [you] a little buggy"?

Are there bugs you haven't reported?

What bugs exactly?

Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system

[Richard Braakman]

On Sat, May 19, 2001 at 07:55:13PM +0300, Anton Zinoviev wrote:
> A maintainer can and may not be aware of the needs of some task.  An
> example: why the maintainer of recode should know that some of the
> filters of magicfilter needs recode and that magicfilter belongs to the
> task printing?

Hmm... all along I've assumed that the task selection process will
at some point pull in all the dependencies of the selected tasks.
Is this the case?

Richard Braakman

Bug#97755: PROPOSAL] eliminating task packages; new task system

[Manoj Srivastava]

Hi,
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

 >> Mind you, I like the proposal, and were it not for the issue
 >> of timing, I would probably have seconded this.

 Joey> It's all about timing, unfortunatly -- we have to get this done before
 Joey> woody base is frozen, and that includes getting the old task packages
 Joey> removed. I think we will though, and will probably have it almostly
 Joey> completly implemented by the time the discussion period is up and it
 Joey> goes into policy.

But what's the driving necessity to get this into policy in a
 hurry? We can't use policy to bludgeon people into removing their
 packages; that has to come from agreements reached with authors of
 the packages themselves, from the DPL, or a general resolution. 

We can then put this all into policy sometime in sarge, after
 the dust has settled down, and the battle plan has actually made
 contact with deployment and bug and the myriad strange systems out
 there.

I have yet to see a reason for rushing into policy something
 that is a proposed process, and not yet a documentation of tried,
 stable, and current practice, Obviously, I am missing something.

manoj
-- 
 You can bear anything if it isn't your own fault. Katharine Fullerton
 Gerould
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#87510: I second this proposal

[Julian Gilbey]

On Fri, May 18, 2001 at 11:08:01PM +0200, Peter Palfrader wrote:
> >  The other is that it's completely wrongheaded
> > to convert a policy from being entirely optional (you /may/ declare
> > build-depends) straight to being compulsory.
> 
> Section 2.4.2 says /should/:

Yes, policy is currently riddled with such inconsistencies.  It's a
significant bug that needs sorting out over the next 3-6 months.  I
have a gameplan, but am not yet ready to work on it.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Bug#87510: I second this proposal

[Anthony Towns]

On Sat, May 19, 2001 at 10:49:28PM +0100, Julian Gilbey wrote:
> On Fri, May 18, 2001 at 11:08:01PM +0200, Peter Palfrader wrote:
> > >  The other is that it's completely wrongheaded
> > > to convert a policy from being entirely optional (you /may/ declare
> > > build-depends) straight to being compulsory.
> > Section 2.4.2 says /should/:
> Yes, policy is currently riddled with such inconsistencies.  It's a
> significant bug that needs sorting out over the next 3-6 months.  I
> have a gameplan, but am not yet ready to work on it.

For reference, anything that ought to be fixed in policy for woody needs to
be done in the next one month.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpt7euwFFrIm.pgp
Description: PGP signature

Bug#97755: PROPOSAL] eliminating task packages; new task system

[Anthony Towns]

On Sat, May 19, 2001 at 03:32:17PM -0500, Manoj Srivastava wrote:
>   But what's the driving necessity to get this into policy in a
>  hurry? 

Because tasks are an important component of making the installer usable,
and they're currently completely broken (in that around half of the
existing tasks in sid simply shouldn't be tasks; and the remaining half
have documentation bugs, or don't include a quite optimal set of packages,
or similar).

Further, the current tasks make it significantly harder to cope with a
freeze, since the task package has to be manually fixed and reuploaded

>  We can't use policy to bludgeon people into removing their
>  packages; that has to come from agreements reached with authors of
>  the packages themselves, from the DPL, or a general resolution. 

Tasks need to be fixed by woody.

Thus, all the task-* packages in woody misleading at best, useless
at worst.

Thus they ought to get removed before release.

If they're not meant to be in woody, we should put this in policy
somewhere. Since policy's meant to be the place where we can discuss
technical changes to Debian that affect multiple packages.

I'm not sure why you think it's not appropriate for policy to be here:
this isn't a matter of packages sucking, it's a matter of having a
special, reserved name space that needs cleaning up.

>   I have yet to see a reason for rushing into policy something
>  that is a proposed process, and not yet a documentation of tried,
>  stable, and current practice, Obviously, I am missing something.

That we're freezing shortly?

Cheers,
aj, not seeing much evidence of policy being "lightweight"

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)

Tightening up specification of /bin/sh

[Zack Weinberg]

Currently the only requirements on the shell interpreter /bin/sh are
that it should adhere to the relevant POSIX standard, and that "echo
-n" should not produce a newline.  Unfortunately, POSIX leaves a large
number of shell features unspecified.  In most of these cases there is
general agreement among shell implementations as to what the behavior
should be, and scripts therefore come to rely on those behaviors.
Policy does not prevent any given /bin/sh from changing these, but
massive breakage can result if they are changed.

I'd like to tighten this up a bit by requiring that /bin/sh adhere to
the consensus of implementations, where POSIX leaves things
unspecified.  What follows is one possible revision.  The wording
isn't ideal; I'm open to suggestions.

zw

*** policy.sgml-3.5.4.0 Fri May  4 00:18:15 2001
--- policy.sgml Fri May  4 00:41:13 2001
***
*** 5332,5368 
  command.
  

! The standard shell interpreter `/bin/sh' can be a
! symbolic link to any POSIX compatible shell, if echo
!   -n does not generate a newline.
  

! Debian policy specifies POSIX behavior for /bin/sh, but
! echo -n has widespread use in the Linux community
! (including especially debian policy, the linux kernel
! source, many debian scripts, etc.).  This echo -n
! mechanism is valid but not required under POSIX, hence
! this explicit addition. Also, rumour has it that this
! shall be mandated under the LSB anyway.

  
! Thus, shell scripts
! specifying `/bin/sh' as interpreter should only
! use POSIX features. If a script requires non-POSIX
! features from the shell interpreter, the appropriate shell
! must be specified in the first line of the script (e.g.,
  `#!/bin/bash') and the package must depend on the
  package providing the shell (unless the shell package is
! marked `Essential', e.g., in the case of
! bash).
!   
  

! You may wish to restrict your script to POSIX features when possible 
so
! that it may use /bin/sh as its interpreter. If
! your script works with ash, it's probably
! POSIX compliant, but if you are in doubt, use
! /bin/bash.
  

  Perl scripts should check for errors when making any
--- 5332,5394 
  command.
  

! The standard shell interpreter `/bin/sh' is a
! symbolic link to a POSIX compatible shell.  Since the POSIX
! standard for shells leaves important areas unspecified,
! wherever it is lacking, `/bin/sh' shall follow the
! consensus behavior of other shell interpreters.
! Consensus behavior is determined by testing at least five
! shell interpreters which claim to be POSIX compatible.  If
! most of them do the same thing, `/bin/sh' must
! behave that way.  Otherwise, `/bin/sh' should
! pick the most sensible of the observed behaviors, in the
! judgement of its maintainer.
  

! Examples of behavior which is determined by consensus
! include the effect of echo -n, and the initial
! value of the IFS variable.
! 
!   
! In Debian, suitable shells for this test include
! pdksh, ash, and bash.  The
! shells shipped as /bin/sh by the various BSD
! distributions are also suitable (these are not the same
! as ash, despite its package description).
! Various shells shipped with proprietary UNIXes, in
! particular the genuine AT&T ksh, are also
! useful to test.
! 
!   
! Care should be taken to ensure that one does not test
! the same implementation under multiple guises.

  
! echo -n is explicitly required to print the
! remainder of its arguments, but no newline.  (Many, but not
! most, of POSIX shells do this.)
! 
!   
! Shell scripts which specify `/bin/sh' as their
! interpreter should only use features specified by POSIX.
! Where POSIX leaves behavior unspecified, they may rely on
! behavior determined by consensus.  If there is no consensus,
! scripts may not rely on the behavior.
! 
!   
! If a script requires non-POSIX features from the shell
! interpreter, it must name the appropriate shell explicitly
! in the first line of the script (e.g.,
  `#!/bin/bash') and the package must depend on the
  package providing the shell (unless the shell package is
! marked `Essential', as bash is).
  

! You are encouraged to restrict your script to POSIX features
! and consensus behavior, whenever possible, so that it may
! use

Bug#97755: PROPOSAL] eliminating task packages; new task system

[Manoj Srivastava]

-BEGIN PGP SIGNED MESSAGE-

Hi,
>>"Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:

 Anthony> Because tasks are an important component of making the
 Anthony> installer usable, and they're currently completely broken
 Anthony> (in that around half of the existing tasks in sid simply
 Anthony> shouldn't be tasks; and the remaining half have
 Anthony> documentation bugs, or don't include a quite optimal set of
 Anthony> packages, or similar).

I'll take your word that task packages, as they exist now, are
 buggy. This, of course, has nothing to do with new policy. 

 Anthony> Further, the current tasks make it significantly harder to
 Anthony> cope with a freeze, since the task package has to be
 Anthony> manually fixed and reuploaded 

Fine. The old task-packages are broken, you have a replacement
 scheme. Fine and dandy. At some point it may even become policy. 


 >> We can't use policy to bludgeon people into removing their
 >> packages; that has to come from agreements reached with authors of
 >> the packages themselves, from the DPL, or a general resolution. 

 Anthony> Tasks need to be fixed by woody.

So? What does this have to do with policy? 

 Anthony> Thus, all the task-* packages in woody misleading at best, useless
 Anthony> at worst.

So? What does this have to do with policy? 

 Anthony> Thus they ought to get removed before release.

You are the release manager. File the bugs, declare them
 release critical, say that the new scheme is golden, and do what you
 wish with the release. Arrange with task package authors to withdraw
 the packages, or rule that the packages are too buggy to make it into
 woody. Do not drag policy into this.

 Anthony> If they're not meant to be in woody, we should put this in
 Anthony> policy somewhere.

Eh? No. If you want to do it the policy way, you propose the
 change, giving a upgrade path. And in woody +1 the may becomes a
 should, and in woody +2 the task packages shall go away. Policy is
 not a club. Policy is not meant to make all the task packages
 suddenly release critical

 Anthony> Since policy's meant to be the place where we can discuss
 Anthony> technical changes to Debian that affect multiple packages.

I like the techical discussion. We should implement it by
 woody + 2, if you want policy to do what it does.  Policy changes do
 not suddenly make packages have RC bugs. 

 Anthony> I'm not sure why you think it's not appropriate for policy
 Anthony> to be here: 

It is. Shall I change the language to have this implemented by
 woody + 2? I 'll second the proposal then.

 Anthony> this isn't a matter of packages sucking, it's a matter of having a
 Anthony> special, reserved name space that needs cleaning up.

And clean up we shall. The timing is where this proposal is
wrong. 

 >> I have yet to see a reason for rushing into policy something
 >> that is a proposed process, and not yet a documentation of tried,
 >> stable, and current practice, Obviously, I am missing something.

 Anthony> That we're freezing shortly?

That is irrelevant  IMHO. Policy has a modus operandi. and not
 even the release manager should ram their changes through

 Anthony> Cheers,
 Anthony> aj, not seeing much evidence of policy being "lightweight"

Policy is not what you think it is, and attempting to use
 policy as a club should never be light weight.

Additionally, gentlemen, unless you can come up with technical
 reasons why we should waive the way policy works in this special case
 (and not the other special cases other people come up with), please
 consider this a formal objection to this proposal. 

manoj

- -- 
 Everything happens at the same time with nothing in between.  -- Paul
 Hebig
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 


iD8DBQE7B0PKIbrau78kQkwRAXkDAKDfZwn29qtjFFdDFTyP2dHNK22pXwCgqwpU
Gg25yOdjCgu1GoS1wQfvbv0=
=Ro6O
-END PGP SIGNATURE-

Re: Bug#97755: PROPOSAL] eliminating task packages; new task system

[Anthony Towns]

>   You are the release manager. File the bugs, declare them
>  release critical [...]

Okay. Whatever. I really don't have the patience for -policy anymore.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpbyOXUnzhRY.pgp
Description: PGP signature