>>>>> "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]
