Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 11:04:34PM -0400, Joey Hess wrote:
> Anthony Towns wrote:
> > Or moving them into the task package themselves, but not in the control
> > record? Or shall we just forget I suggested that originally.
> Well, I had. 

Well, it's possible I wasn't explicit enough. What I said was:

] This was discussed on -devel just after potato released, I think consensus
] was that we should use override files to populate these fields, rather
] than letting maintainers add their own packages directly to tasks. I'm
] not sure if we came to a consensus about how these override files would
] be maintained though (or who by: ftpmaster? -boot? the individual task-*
] maintainers?). It's probably best to put it in boot-floppies CVS, and have
] dinstall use that.

It's not remotely difficult to put the overrides in the dinstall
database where they can only be modified by ftpmaster, or to have the
dinstall cronjob update from boot-floppies CVS, or to extract them
automatically from individual task.debs direct from the pool. I still
think boot-floppies CVS would be the best compromise between ease of
access (since all developers have access to it, all maintainers pretty
much do too...) and ease of implementation (cvs checkouts are pretty
straightforward to automate).

But hey, easier to jump off the deep end than try working out the best
solution or building consensus, right?

Now that www.d.o is back up, I'll again cite the URL for the discussion
we had about this: http://lists.debian.org/debian-devel-0008/msg00700.html.
Some others of note:

http://lists.debian.org/debian-devel-0008/msg00711.html
http://lists.debian.org/debian-devel-0008/msg00700.html

See particularly the last three paragraphs of that last one.

> That's a reasonable alternative. Oh, except, I seem to remember you wanted
> to use some special-purpose field for it, when we again have perfectly
> good general purpose fields, Suggests and Recommends, that already do the 
> same thing.

Except they don't. Recommends is (quite reasonably) treated exactly the
same as Depends by dselect, and even missing suggests are complained
about ocassionally.

If I've suggested anything specific at all, btw, it wasn't anything in
their control file, but rather an extra file in /usr/share/doc or similar.
*shrug*

> > > * Eliminate all usefulness of tasks except when manipulated by one 
> > >   single special purpose tool (tasksel). (This includes making it
> > >   impossible to install a task and receive bugfix upgrades to it later.)
> > Yeah, because hey, if the tools aren't written now (or at the very least
> > mandated by policy) it'll be impossible to ever write them in future.
> I think it very unlikely that we will ever get support for some hackish
> field only used by task packages into Dselect, and Dpkg, and Apt, and
> Aptitude, and Deity, and Red Carpet and ...

Yeah, because those maintainers care a whole lot more about whether
something's inelegant rather than whether or not it works. Better to
not let people manage tasks at all than to do *that*.

> > > AJ asked for a concrete counterpropsal, and this is mine: If you really
> > > want to do this, just go back to Bruce's system. Redo it so it's not so
> > > blasted ugly and confusing, fix the self-destructive aspect, but use the
> > > same idea. Which likely means just hardcoding the tasks and what
> > > packages comprise them in tasksel, and when a task is selected, have apt
> > > install all available packages that are in the task.
> > "Forget all the code that exists and is working right now, and rewrite it
> > based on this old code that everyone's forgotten."
> Bruce's stuff was not so bad. Aside from being a rushed implementation,
> the idea was pretty good.
> see shy jo, ignoring certian nuances

Let me spell it out for you then: there is nothing concrete about
unwritten code.

If you'd wanted to get this fixed in your own special way, you've had nine
months to work out what you want. You've had nine months to reconsider
your agreement to the "Task:" idea. You've had nine months to go out
and implement something. But you didn't, so eventually I went out and
did what we'd discussed on -devel nine months ago. And now, of course,
you've decided that it offends your sense of aesthetics, and therefore
must absolutely *never* happen, and that I'm a completely unreasonable
little bigot for daring to propose such a thing.

Am I misreading something here? Is there something that tasks are
currently useful for that a combination of "Task:" fields and non task
metapackages doesn't work for? If so, there's a real problem with this
solution that needs to be fixed, and you're welcome to ignore any and
all insinuations so we can get on with that.

If not, though, are you seriously exaggerating a difference in taste
and perhaps some wishlists that no one's been bothered enough to try
implementing to the whole proposal being based on (how did it go again?)
"a horrid assumption, [that] says 

Re: Submitting bugs/ideas

[Chris Tillman]

> Hi, This is probably a newbie question, but I've found a few bugs and I 
> dont know how/where to post them, if someone could show me how, I'd be much
obliged
>
> thanks-
> Andrew
>

Take a look at


http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=boot-floppies&archive=no

to be sure your bugs are really undiscovered; then follow the guidelines at

http://www.debian.org/Bugs/Reporting

to submit them. Thanks for your interest!

--

Chris Tillman
[EMAIL PROTECTED]


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

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> Or moving them into the task package themselves, but not in the control
> record? Or shall we just forget I suggested that originally.

Well, I had. 

That's a reasonable alternative. Oh, except, I seem to remember you wanted
to use some special-purpose field for it, when we again have perfectly
good general purpose fields, Suggests and Recommends, that already do the 
same thing.

> > * Eliminate all usefulness of tasks except when manipulated by one 
> >   single special purpose tool (tasksel). (This includes making it
> >   impossible to install a task and receive bugfix upgrades to it later.)
> 
> Yeah, because hey, if the tools aren't written now (or at the very least
> mandated by policy) it'll be impossible to ever write them in future.

I think it very unlikely that we will ever get support for some hackish
field only used by task packages into Dselect, and Dpkg, and Apt, and
Aptitude, and Deity, and Red Carpet and ...

This is why I have been trying to generalize the thing all along. A more
general purpose field will be more generally used, and so people will
have more incentive to implement it. Plus, it probably solves some other
problems out side of task space.

> > AJ asked for a concrete counterpropsal, and this is mine: If you really
> > want to do this, just go back to Bruce's system. Redo it so it's not so
> > blasted ugly and confusing, fix the self-destructive aspect, but use the
> > same idea. Which likely means just hardcoding the tasks and what
> > packages comprise them in tasksel, and when a task is selected, have apt
> > install all available packages that are in the task.
> 
> "Forget all the code that exists and is working right now, and rewrite it
> based on this old code that everyone's forgotten."

Bruce's stuff was not so bad. Aside from being a rushed implementation,
the idea was pretty good.

-- 
see shy jo, ignoring certian nuances


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

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 10:34:26PM -0400, Joey Hess wrote:
> * Move control of what packages a task includes out of the hands of the
>   creator of the task, and into the hands of people who have commits to
>   some cvs repository somewhere[1].

Like boot-floppies CVS which every developer and a few non-developers
have commit access to?

Or moving them into the task package themselves, but not in the control
record? Or shall we just forget I suggested that originally.

Yes, clearly it's a power trip and I don't trust anyone else. Why,
I'm evil and thoughtless and just plain baaad.

> * Eliminate all usefulness of tasks except when manipulated by one 
>   single special purpose tool (tasksel). (This includes making it
>   impossible to install a task and receive bugfix upgrades to it later.)

Yeah, because hey, if the tools aren't written now (or at the very least
mandated by policy) it'll be impossible to ever write them in future.

> AJ asked for a concrete counterpropsal, and this is mine: If you really
> want to do this, just go back to Bruce's system. Redo it so it's not so
> blasted ugly and confusing, fix the self-destructive aspect, but use the
> same idea. Which likely means just hardcoding the tasks and what
> packages comprise them in tasksel, and when a task is selected, have apt
> install all available packages that are in the task.

"Forget all the code that exists and is working right now, and rewrite it
based on this old code that everyone's forgotten."

Feh.

Cheers,
aj, getting fed up with trying to help

-- 
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)

 PGP signature

Re: Tasks policy

[Joey Hess]

It occurs to me that what AJ's trying to do and its results can perhaps be
restated as follows (with apologies to AJ -- you have the best of
intentions):

* Move control of what packages a task includes out of the hands of the
  creator of the task, and into the hands of people who have commits to
  some cvs repository somewhere[1].
* Eliminate all usefulness of tasks except when manipulated by one 
  single special purpose tool (tasksel). (This includes making it
  impossible to install a task and receive bugfix upgrades to it later.)

But the only real differences between this proposed system and the system
Bruce wrote hurredly over Xmas for hamm or so are:

* In this system, we have these useless task-* packages cluttering up tools
  that cannot use them, while in Bruce's system, the tasks were hidden
  out of the way.
* Maintainers of task packages do get to provide a description of the
  task. In AJ's system, that's really all maintaining a task package means
  -- you maintain a package description, and nothing more.
* In Bruce's system, the task selector self-destructed and was not
  callable after install.

AJ asked for a concrete counterpropsal, and this is mine: If you really
want to do this, just go back to Bruce's system. Redo it so it's not so
blasted ugly and confusing, fix the self-destructive aspect, but use the
same idea. Which likely means just hardcoding the tasks and what
packages comprise them in tasksel, and when a task is selected, have apt
install all available packages that are in the task.

If we need a quick fix for the task problem in time for the freeze, this
is it. 

-- 
see shy jo

[1] The more I think about it, the more the reasons for this incense me.
All this talk of overrides files has the unstated assumption that we
cannot simply file bugs on packages, and get their maintainers to
add the appropriate Task: or Enhances: or whatever fields. This is a
horrid assumption, and it says bad things about either the state of
Debian or the assumptee.


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

Processed: tags

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tags 95851 fixed
Bug#95851: modconf: Galician translation of modconf's templates
Tags added: fixed

> This has been applied to modconf cvs.
Unknown command or malformed arguments to command.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Darren Benham
(administrator, Debian Bugs database)


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

Submitting bugs/ideas

[Bucky0]

Hi, This is probably a newbie question, but I've found a few bugs and I dont know 
how/where to post them, if someone could show me how, I'd be much obliged

thanks-
Andrew


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

Re: Tasks policy

[Jason Gunthorpe]

On Wed, 9 May 2001, Anthony Towns wrote:

> On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> > I don't recall a discussion of or decision on using overrides files.
> 
> Well, uh, you were in it...
> 
> "Overrides files" may not be quite the most accurate way of expressing it.
> Certainly, I don't mean overrides files that ftpmaster takes care of.

If it is possible to do it without override files then that should be the
prefered solution.

Otherwise getting the Task: information reliably into the status file will
be very hard and I think having task information there will be very
important in future.

Jason


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

cvs commit to modconf/template by dwhedon

[dwhedon]

Repository: modconf/template
who:dwhedon
time:   Tue May  8 18:09:47 PDT 2001


Log Message:

Galician translation of modconf's templates
contributed by [EMAIL PROTECTED]


Files:

added:  eval_gl.fixed


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

cvs commit to modconf/debian by dwhedon

[dwhedon]

Repository: modconf/debian
who:dwhedon
time:   Tue May  8 18:09:46 PDT 2001


Log Message:

Galician translation of modconf's templates
contributed by [EMAIL PROTECTED]


Files:

changed:changelog


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

cvs commit to modconf by dwhedon

[dwhedon]

Repository: modconf
who:dwhedon
time:   Tue May  8 18:09:46 PDT 2001


Log Message:

Galician translation of modconf's templates
contributed by [EMAIL PROTECTED]


Files:

changed:Makefile


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

cvs commit to debian-installer/tools/ddetect/debian by dwhedon

[dwhedon]

Repository: debian-installer/tools/ddetect/debian
who:dwhedon
time:   Tue May  8 17:45:20 PDT 2001


Log Message:

German translations contributed by Sebastian Feltel <[EMAIL PROTECTED]>


Files:

changed:changelog ethdetect.templates


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

cvs commit to debian-installer/tools/niccfg/debian by dwhedon

[dwhedon]

Repository: debian-installer/tools/niccfg/debian
who:dwhedon
time:   Tue May  8 17:37:43 PDT 2001


Log Message:

This tools isn't necessary anymore.



Files:

removed:changelog control copyright menutest niccfg-manual.templates rules


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

cvs commit to debian-installer/tools/niccfg by dwhedon

[dwhedon]

Repository: debian-installer/tools/niccfg
who:dwhedon
time:   Tue May  8 17:37:43 PDT 2001


Log Message:

This tools isn't necessary anymore.



Files:

removed:Makefile TODO niccfg-manual.c utils.c utils.h


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

Bug#96793: boot-floppies build depends on nonexistant debiandoc.decl

[bame]

package: boot-floppies
version: CVS-8-may-2001

Trying to build boot-floppies on parisc/hppa (so take this with a grain
of salt), documentation/Makefile depends on debiandoc.decl which used
to be delivered by debiandoc-sgml (e.g., version 1.1.44) but which is
no longer available (checked 1.1.46 and 1.1.47).


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

cvs commit to base-config by joeyh

[joeyh]

Repository: base-config
who:joeyh
time:   Tue May  8 13:34:09 PDT 2001


Log Message:

   * Reworded the "simple, advanced" question, adding a third option
 to not install anything more. All translations need to be updated..
   * Removed PERL_BADLANG hack. If the boot floppies are not setting a
 proper LL_ll language code, and are setting LANG=LL instead, this will
 cause nasty perl messages. Let's find out..
   * Only ask about removing pcmcia if PCMCIA is set, but not "yes".
 If it is unset, this is probably not a fresh install (and having it
 always ask about removing pcmcia from my laptop during testing was
 getting to be a pita).

Files:

changed:stage2 stage3


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

cvs commit to base-config/debian by joeyh

[joeyh]

Repository: base-config/debian
who:joeyh
time:   Tue May  8 13:34:09 PDT 2001


Log Message:

   * Reworded the "simple, advanced" question, adding a third option
 to not install anything more. All translations need to be updated..
   * Removed PERL_BADLANG hack. If the boot floppies are not setting a
 proper LL_ll language code, and are setting LANG=LL instead, this will
 cause nasty perl messages. Let's find out..
   * Only ask about removing pcmcia if PCMCIA is set, but not "yes".
 If it is unset, this is probably not a fresh install (and having it
 always ask about removing pcmcia from my laptop during testing was
 getting to be a pita).

Files:

changed:changelog config postinst templates


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

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> > of re-overloading the package name. I think all those names are very, very
> > ugly. Wouldn't this be nicer --
> > Package: task-desktop
> > Tasksel-Section: user
> > Package: task-web-server
> > Tasksel-Section: servers
> 
> Well, I mentioned somewhere having a separate section for tasks. We could
> have more than one, and make it:
> 
>   Package: task-desktop
>   Section: user-tasks
> 
>   Package: task-web-server
>   Section: server-tasks

I would prefer something like this.

> > It's worth noting that for a good 3 or 4 months after potato's release,
> > new installs that used tasksel did not get emacs or tex, or anything
> > else in standard,
> 
> (Note that everyone who wanted TeX probably chose "task-tex" anyway)

Well, ok, but nobody complained about a missing task-emacs anyway.

-- 
see shy jo


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

cvs commit to debian-installer/tools/ddetect/debian by dwhedon

[dwhedon]

Repository: debian-installer/tools/ddetect/debian
who:dwhedon
time:   Tue May  8 12:14:21 PDT 2001


Log Message:

change to priority standard


Files:

changed:control


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

Re: Tasks policy

[Anthony Towns]

On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> I don't recall a discussion of or decision on using overrides files.

Well, uh, you were in it...

"Overrides files" may not be quite the most accurate way of expressing it.
Certainly, I don't mean overrides files that ftpmaster takes care of.

Unfortunately www.debian.org seems to be down, so I can't cite a url for
the discussion from a while ago, but the summary is basically that during
the freeze (ie, when I start removing packages left right and centre),
it's very easy for a task to get broken if task-membership is specified
as part of the task. If, instead, it's specified as part of the package
that's in the task, once the package is removed, the fact that it was
meant to be in the task disappears too, and fewer things break.

On the other hand, the way tasks currently work, with a single person
choosing which packages go in a task works fairly well (as you've said),
so that's something worth preserving. The way we can preserve that is
with override files.

> I also don't understand why this new Task: header is being introduced.

I'd encourage you to reread the thread from last year. I posted a URL
earlier in the thread.

> > * tasks should be priority optional (and thus packages in
> >   tasks should be priority optional),
> I think you mean the packages in a task should be option or higher (not
> extra), right?

Well, whatever. If they're standard or higher, they'll be installed
anyway, so it doesn't much matter. But yeah, that's all I was getting at.
It also brings into play the "don't Conflict: with other things" rules
from elsewhere.

> > * tasks should follow a naming convention so they can be organised
> >   better by tasksel. Probably:
> > task-devel-{c,c++,objc,haskell,...}
> > task-lang-{german,french,japanese,chinese,...}
> > task-server-{web,news,mail,database,dns,...}
> > task-user-{desktop,office,games,junior,...}
> > task-hware-{dialup,printer,laptop,...}
> Well we could let tasksel use the Section field, or some new field instead
> of re-overloading the package name. I think all those names are very, very
> ugly. Wouldn't this be nicer --
> Package: task-desktop
> Tasksel-Section: user
> Package: task-web-server
> Tasksel-Section: servers

Well, I mentioned somewhere having a separate section for tasks. We could
have more than one, and make it:

Package: task-desktop
Section: user-tasks

Package: task-web-server
Section: server-tasks

> Or even (why overload package the field at all) --

...because we're already doing it, and because it helps separate tasks
in existing UIs.

> Or even this (the only problem with it is that our current set of
> sections is so limited and hard to change) --

Sections are adminned by overrides by ftpmaster. There just needs a
good reason to create a new one (well, and some patience), it's not
really difficult.

> It's worth noting that for a good 3 or 4 months after potato's release,
> new installs that used tasksel did not get emacs or tex, or anything
> else in standard,

(Note that everyone who wanted TeX probably chose "task-tex" anyway)

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)

 PGP signature

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 12:19:20PM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
> Anthony> You
> Anthony> check the code out from CVS, or do an apt-get source, you
> Anthony> write the code, and you send it to Randolph. It doesn't
> Anthony> need discussion here.
> I resent the implication that I'm responsible for fixing any problem
> that I discover.

Eh?

Seriously, it's quite easy. That's how "Task:" got implemented. I ran
"apt-get source", read the code 'til I understood it, implemented it,
did some testing, sent the patch to Randolph, and it got into the archive.

> I believe there is value in pointing out a problem
> report even if you don't have the resources to fix it.

What do you mean you don't have the resources to fix it? The code's all
right there. There're debuggers, and compilers and everything. There's
no licensing restrictions in your way. There's not even any controversy
about whether it'd be a Good Thing. It's not even hard.

(If you're trying to say you don't have the skill to fix it, then, quite
frankly, you probably shouldn't be trying to insist on what others should
be doing.)

> Anthony> Not really. Frontends should do whatever their authors
> Anthony> deem appropriate and have time to implement. If you want
> Anthony> to send in patches, or write your own frontend, more
> Anthony> power to you. It's not policy's place to say anything
> Anthony> about what features you should and shouldn't implement
> Anthony> though.
> I disagree in general; [...]

That doesn't really surprise me. It's much more fun to disagree about
things than to fix them. Even when it's not actually easier.

For reference:

--- tasksel-1.1/tasksel.c   Tue Apr 24 16:35:07 2001
+++ tasksel-1.2aj/tasksel.c Wed May  9 02:56:26 2001
@@ -176,6 +176,21 @@
   }
 
   tasklist = tasks_enumerate(&tasks);
+  if (noninteractive) {
+for (;optind < argc; optind++) {
+  /* mark task argv[optind] for install, if it exists */
+  int i;
+  for (i = 0; i < tasks.count; i++) {
+if (strcmp(tasklist[i]->name, argv[optind]) == 0) break;
+  }
+  if (i == tasks.count) {
+printf("E: %s: no such task\n", argv[optind]);
+  } else {
+tasklist[i]->selected = 1;
+  }
+}
+  }
+
   if (r == 0) {
 r = doinstall(tasklist, tasks.count,
  pkglist, (installreqd || installimp || installstd 


Getting a nice command line, rather than just the simplest to implement
is left as an exercise to the interested reader.

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)

 PGP signature

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.

Amen.

> tasksel in sid supports a "Task:" header for packages so we can be a
> little more flexible than having every task- depend on everythig in it.
> This was discussed on -devel just after potato released, I think consensus
> was that we should use override files to populate these fields, rather
> than letting maintainers add their own packages directly to tasks. I'm
> not sure if we came to a consensus about how these override files would
> be maintained though (or who by: ftpmaster? -boot? the individual task-*
> maintainers?). It's probably best to put it in boot-floppies CVS, and have
> dinstall use that.

I don't recall a discussion of or decision on using overrides files.
While it seems that letting developers create task packages willy-nilly
with no rules or supervision has been a disaster, the overall quality of
the dependnaices in individual tasks is ok, so I see no need to have
centralized control over that. Bug reports suffice. So no need for overrides
files.

I also don't understand why this new Task: header is being introduced. I
mean, I understand why you don't want to use dependancies. But why not
let tasks use Recommends and Suggests in a sensible fashion, and simply
make tasksel install all packages listed in either field by a task package?
This would make tasks usable in eg, dselect and any other decent apt
frontend, and it wouldn't add a new, seemingly hackish field.

>   * tasks should be priority optional (and thus packages in
> tasks should be priority optional),

I think you mean the packages in a task should be option or higher (not
extra), right?

>   * tasks should follow a naming convention so they can be organised
> better by tasksel. Probably:
>   task-devel-{c,c++,objc,haskell,...}
>   task-lang-{german,french,japanese,chinese,...}
>   task-server-{web,news,mail,database,dns,...}
>   task-user-{desktop,office,games,junior,...}
>   task-hware-{dialup,printer,laptop,...}

Well we could let tasksel use the Section field, or some new field instead
of re-overloading the package name. I think all those names are very, very
ugly. Wouldn't this be nicer --

Package: task-desktop
Tasksel-Section: user

Package: task-web-server
Tasksel-Section: servers

Or even (why overload package the field at all) --

Package: desktop
Task: yes
Tasksel-Section: user

Package: web-server
Task: yes
Tasksel-Section: servers

Or even this (the only problem with it is that our current set of
sections is so limited and hard to change) --

Package: desktop
Task: yes
Section: user

Package: web-server
Task: yes
Section: servers

>   * we should have tasks specifically for emacs and tetex (even though
> both could be replaced by a wordprocessor in task-office, say).
> possibly:
>   task-sware-{tetex,emacs}
> and require any additional tasks like this get run through policy
> first. If nothing else, historical reasons are a good argument
> for tetex and emacs, and are obviously immune to slipper
> slopes. :)

It's worth noting that for a good 3 or 4 months after potato's release,
new installs that used tasksel did not get emacs or tex, or anything
else in standard, and that although people eventually complained about
other packages in standard not being installed, I never saw a single
complaint that those two were missing. After all, it didn't affect
upgrades, and I guess people who wanted emacs had no problem with using
apt afterwards.

-- 
see shy jo


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

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> > Would it not be much easier for the task packages _themselves_ to
> > contain Task: fields, instead of the individual packages, which would
> > function like weak Recommends: fields: 
> 
> Not really. The code's already written to do things the other way around,
> and the main point of "Task:" fields being in the package is so that
> packages can be removed from the archive without breaking any tasks they
> might be a part of.

I recently sent a mail questioning the Task: field. Seems I have
misunderstood (I thought it was intended to be a field in task packages,
listing the packages in the task). Now that I understand, I support Aj's
proposal wholeheartedly, except my thoughts about using sections to
organize tasks, rather than overloding the package name, still stand.

-- 
see shy jo


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

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> You can always run tasksel, select the task, and go "Ok", instead of using
> "apt-get install ..." though. Making "tasksel install server-dns" just go
> ahead and install the task, bypassing the UI, would be fairly simple too.

Another option would be to add real reverse dependancy support to apt
(a Task: field is really a reverse dependancy, if you get what I mean).
Reverse dependancies have other uses, and the lower in the package
manager stack they are supported, the better.

-- 
see shy jo, cringing at the concept of a package manager stack, but
that's what we have now


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

Re: di: seperate preperation and installation phases

[Tim Middelkoop]

I got board one weekend and have done this in a way for
debian-linux-i386 and it works quite well.  I had initially done a
single prep/build environment but it got too messy.  The separation of
phases helped keep the complexity of both systems down.  Phase I is a
good rescue environment and remains solid because it is a contained
environment.  Phase II is a static build envronment which is not that
flexable, but is extreamly robust to upgrading of the production and
prepration environment. It consists of a static busybox with a
script+fstab/interfaces+config that currently take the packages live
from the mirrors and build them the way deboostrap does but with a
much more minimal environment.

This system will build a debian system (in vmware) from one floppy in
one boot which was my original goal. I eventually want to have it run
in intel's PEX environment to build a new lab box in one boot totally
unattended with my some what stable snapshot of the "unstable"
distribution.

Here is an outline of what it does, if anyone is intrested in the
scripts/environment just shoot me some email.

I know this is a lot of duplicated work but I just got board one
weekend and felt the need to know what it realy takes to build a
debian system from as little as possible. (my resuce disks were
also getting a bit crusty too, running linux 2.0.29)

tim...

Phase I
* boot into a rescue disk like environment (reduced libc)
* partition/format/copy phase II enviornment (a single script now)
* write Phase II config
* if (in initrd) then exit and chain phase II ; else reboot

Phase II
* boot into static busybox environment and run phase II script as init
* setup network/package source
* download required packages (10)
   - an alternative to this would be to download all 
 phase II/III in phase I since there are not that many packages
* unpack libc6/libstdc/sysvinit/ash/dpkg
* use new dpkg to re-install above 
* use dpkg to install dpkg/apt/perl support
* apt-get dist-upgrade
* processes Phase I config for transfer to phase III
* exec /sbin/init for sane enviornment

Phase III
* run as .bash_login
* apt-get install ??? for interactive setup
* we now have basic debian system ready for installing tasks.

--
Tim Middelkoop  OA straight line may be the shortest
[EMAIL PROTECTED] /\,   distance between two points, but it
http://arranvale.com/mtim\/\ is by no means the most interesting
/-Dr. Who

On Tue, May 08, 2001 at 03:00:37PM +1000, Glenn McGrath wrote:
> If we have a seperate preperation and installation phase then it would
> make the installer more versatile.
> 
> The actual installation phase could be much like what debootsrap does,
> and the preperation stage would involve preparing an environment for
> deboostrap to run.
> 
> The preperation phase could involve
>   - partitioning
>   - network configuration, for deboostrap to use
>   - hardware detection, identify required kernel modules
>   - putting all this in an image somewhere
> 
> The preperation stage would ideally be run in the current environment
> (pre-install), it may be an existing debian machine, a different linux
> distribution or even another OS such as the Hurd (or a BSD?), if no
> previous OS exists then it would have to fall back to a more traditional
> preparation stage.
> 
> The installation phase would be native to the OS being installed, it
> would just have to run this pre made image which would install base to
> the targeted pre-prepared partition.
> 
> We could then install the Hurd from a linux system, or vica versa. It
> would be simpler in a lot of cases to make better use of the previous OS
> rather than always starting from scratch.
> 
> Identifying the stages as seperate may also make it easier to work on as
> it helps break down the problem a bit more.
> 
> (but i havent read the plan for a while, maybe im out of touch)
> 
> 
> Glenn
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


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

Re: Tasks policy

[Sam Hartman]

> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
>> Yes, that was the original point of tasks.  However, tasks are
>> also used today by people who want to get a set of software
>> installed after the initial install.  [...]

>> Yet I understand we have finite time.  Would it be reasonable
>> to get tasksel install task-name added as a command line
>> invocation for people to use in scripts

Anthony> I'm not sure what scripts have to do with anything, but
Anthony> adding a command line option is entirely trivial. 

So, it is very annoying to write a script to go into tasksel, move to
the appropriate task, select it and go down to OK.  If I want to install a task as 
part of some management script,
 I really do need a command line for it.

Anthony> You
Anthony> check the code out from CVS, or do an apt-get source, you
Anthony> write the code, and you send it to Randolph. It doesn't
Anthony> need discussion here.

I resent the implication that I'm responsible for fixing any problem
that I discover.  I believe there is value in pointing out a problem
report even if you don't have the resources to fix it.

I believe that your proposal will break people who are installing
tasks after initial install.  I believe this is sufficiently common
that we don't want to break this usage pattern.  Either I'm right and
we as a policy group have an obligation to make sure that we implement
the change in a manner that does not break our users--this obligation
existing regardless of whether I'm willing to go off and write code on
this particular issue, or I'm wrong and I'm simply asking for a
feature request.

I'm sorry I don't have a good way to give you evidence on how common the usage pattern 
of installing tasks after initial install is.  I've considered ways of getting this 
info, and the best thing I've found so far is asking users.




>> and to have the policy text say that frontends that handle
>> recommends should handle tasks? =20

Anthony> Not really. Frontends should do whatever their authors
Anthony> deem appropriate and have time to implement. If you want
Anthony> to send in patches, or write your own frontend, more
Anthony> power to you. It's not policy's place to say anything
Anthony> about what features you should and shouldn't implement
Anthony> though.

I disagree in general; there are cases where interoperability requires
us to recommend or even require features be implemented.  However, I
agree that would be going to far.  I believe that by describing parts
of a protocol like the format of the packages file entry you are
implicitly saing that users of that protocol should implement the
parts of that protocol that are appropriate for their application.  I
think a footnote indicating that we are changing from a model where
tasks depend on a lot of stuff to one where they reverse-recommend
means that some users may still expect to be get useful results by
installing a task package.


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

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 09:55:48AM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
> Anthony> Remember: the point of tasks is to make the initial
> Anthony> install simpler, so that people can get started on Debian
> Anthony> without having to wade through dselect.
> Yes, that was the original point of tasks.  However, tasks are also
> used today by people who want to get a set of software installed after
> the initial install.  [...]

> Yet I understand we have finite time.  Would it be reasonable to get
> tasksel install task-name added as a command line invocation for
> people to use in scripts

I'm not sure what scripts have to do with anything, but adding a command
line option is entirely trivial. You check the code out from CVS, or do
an apt-get source, you write the code, and you send it to Randolph. It
doesn't need discussion here.

> and to have the policy text say that
> frontends that handle recommends should handle tasks?  

Not really. Frontends should do whatever their authors deem appropriate
and have time to implement. If you want to send in patches, or write
your own frontend, more power to you. It's not policy's place to say
anything about what features you should and shouldn't implement though.

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)

 PGP signature

Re: Tasks policy

[Sam Hartman]

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


Anthony> On Mon, May 07, 2001 at 07:32:10PM -0400, Sam Hartman
Anthony> wrote:
>> So, I think that support in tools besides tasksel is critical
>> to this policy proposal being useful.  I don't like the idea of
>> having frontend-specific fields being mandated by policy and
>> don'tt see a need for tasksel to be a distinguished frontend.
>> I understand why apt-get might not want to support or
>> reverse-recommends, but I think that the actual frontends
>> should support this.

Anthony> Remember: the point of tasks is to make the initial
Anthony> install simpler, so that people can get started on Debian
Anthony> without having to wade through dselect.

Yes, that was the original point of tasks.  However, tasks are also
used today by people who want to get a set of software installed after
the initial install.  I know many Debian users who expect to be able
to do apt-get install task-blah long after the initial install. While
I was not involved as a developer at the time this discussion happened
the last time, I saw a major advantage of tasks over profiles that I
could install new tasks as I found I needed them rather than having to
reinstall a system and select a new profile.

We will never fully be able to support the users who have grown used
to being able to apt-get install tasks; you have convinced me of that.
However policy's primary purpose seems to be to document existing
practice and I don't think that we are doing that very well by
dropping support for the existing practice of usefully adding tasks
after the initial install.

Yet I understand we have finite time.  Would it be reasonable to get
tasksel install task-name added as a command line invocation for
people to use in scripts and to have the policy text say that
frontends that handle recommends should handle tasks?  I'm not
particularly concerned about the specifics of the text, but I believe
we must allow people an option to continue to use tasks in interactive
scripts and we should encourage people to support it appropriately.

--Sam


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

RE: problem mit neuem kernel, gerätekonflikt etc.

[RIBNITZ Robert]

 Hallo, willkommenm auf der Liste.

a) Kernel 2.4.x braucht die neue version der Modutils, die wiederum die neue
libc6 will. Potato funktioniert aus diesem grunde nicht mit 2.4.x kernel
(dist-upgrade auf woody loest das problem. Wenn es nurt um einfachere USB
funktionen geht, gibt es die auch in 2.2.18 und 2.2.19)

(for the list, I told this guy that to use kernel 2.4 he'd resonmably want
to upgrade to woody)

b) das ist das beschriebene problem der modutils. besorg dir die neuen
modutils, oder upgrade auf woody

Keinerlei idfee wie man usb geraetekonflikte loest.


Gruesse

Robert
-Original Message-
From: je_stromf.set
To: [EMAIL PROTECTED]
Sent: 5/8/01 4:27 AM
Subject: problem mit neuem kernel, gerätekonflikt etc.

hallo,
ich bin neu hier und habe ein paar probleme  betr. 
 
1) booten mit neuem (vorkompil.) Kernel vmlinuz-2.4.1. auf meinem debian
potato 2.2 linux.
der neue kernel steht nach der installation unter /boot
(glaube auch unter /lib/modules und /usr/src etc.) und ich habe in
linuxconf den kernel auch als standard eingetragen.
 
der test cat /proc/version zeigt mir jedoch immer noch den alten kernel.
 
2) probleme habe ich auch mit der einbindung von usb.
es gibt einen gerätekonflikt mit audio/sound-device auf irq 10.
und jetzt habe ich mir auch noch modconf zerschossen! -( , d.h.
irgendwie verweist modconf immer noch auf den alten kernel, wie ich
vermute,
jedenfalls erscheint keine modul-liste mehr)
 
fragen:
-wie kann ich, wenn ich über cd boote (mit dem alten kernel), den neuen
kernel ansprechen?
-wie kann ich modconf wieder zum laufen bringen  (neuinstallation
erfolglos)
-wie kann ich einen USB-gerätekonflikt auflösen
 
gruss
 
j.str.set


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

Re: Tasks policy

[Julian Gilbey]

On Tue, May 08, 2001 at 02:54:59PM +1000, Anthony Towns wrote:
> Remember: the point of tasks is to make the initial install simpler,
> so that people can get started on Debian without having to wade through
> dselect.
> 
> So it's not a problem if *nothing* other than tasksel can handle
> installing and removing tasks elegantly yet. It's unlikely dpkg or apt-get
> will handle tasks directly ever, but perhaps some of the frontends (deity
> or dselect) will eventually. If you want to hack on this at some point,
> that's fine, but getting tasks to work for their primary goal is much
> more important right now.

Totally agreed and understood!

My thought was simply that it would be easier for people to make sense
of if they could just look at the control file of one package
(task-foo) rather than searching through the control files of all
packages.

But again, you have working code, so the point is somewhat moot.

> Task: headers are more akin to Section: headers than Recommends:. Both in
> that people really ought to be able to just uninstall a package if they
> don't like it, and in that the complexity of dependency specifications
> just isn't warranted. It's quite reasonable, for example, to try
> to setup a mail server (with SMTP and POP and IMAP and maybe even a
> webmail application, say) and then decide you'd like to replace exim
> with postfix, eg.

Sort of agreed, which was why I said that it must have a different set
of rules.  Remember that the Task: header will be under the control of
a strictly limited number of packages.

   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/


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