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 realplayer. > 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 > installer. 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
