Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote:
> Right. I just do nt see these invariants being very useful. I
> would much rather have a mk-realplayer package that helps me create a
> realplayer-blah.deb; and the invariants are then natural and not
> artificially imposed. When that realplayer.deb is installed,
> realplayer is installed (duh), and the version of that package tells
> me what version I have installed.
> I can then move the .deb to my local apt-able tree, and all
> other machines in my environemnt can just install this.
> the ml-realplayer does not have to be upgrade every time
> realplayer changes. I can install an older verison of real player if
> I wish (getting it off a CD, or something).
Well I for one find being able to make sure I am upgraded to the current
version is very useful, especially given the historical buginess of
> Joey> If you don't want to download realplayer right now, why are you
> Joey> installing the package?
> It is not useful hectoring the user when they report a
> percieved problem.
I'm not hectoring, I'm asking a question. That is why my sentence ended
with a question mark.
> If we can make it so that people do not have to put thigs on
> hold, would that not be an improvement?
Not really, if it makes it hard for other people to make sure they
always have the mose current version.
> Fine. I prefer to remove this annoyance, though. Consider
> this an ITP for mk-realplayer. I'll probably steal your code rather
> than re-invent the wheel. Since your package is not really the
> realplayer binary, I am asking you to rename it to something else, so
> the package that mk-realplayer creates would not interfere with your
If you want to maintain realplayer, it is yours. I have intended to drop
all my contrib packages anyway.
If, however, you make it difficult to ensure that a machine tracking
stable is not running the current version of realplayer, expect me to
send you bug reports.
I hereby orphan the package.
see shy jo