Re: Tasks policy

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> 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.