This starts out replying to Joey Hess one quote level submerged, but I address some things to you too, Manoj, below. On Fri, Aug 18, 2000 at 05:37:17AM -0500, Manoj Srivastava wrote: > > Joey> Moreover, I find your entire manner in this thread > Joey> insulting. First you come in and state that the entire design > Joey> of this package I have maintained for 3 years is broken by > Joey> design. > > I am sorry you find this insulting. But in all honesty this is > what I do feel about this: I do find packages like this (i believe > the old netscape packages were like this too) to be, umm, > suboptimal. After carefully populating a local mirror, one suddenly > finds, often in the middle of an install, that one needs to download > several hours worth of stuff (not during the preinstall, no). Then > there is no chance of deferring this download -- the whole install > process breaks. by this time, of course, it is too late to hold the > package -- it has been unpacked, but not configured. And it shall > remind you evrey time until you download the darned binary. Yes, I do > consider the design broken. Joey, do me a favor and hear me out completely before getting upset with this, since some of it is likely to touch a nerve and I honestly don't mean it to. I also consider installer packages to be horribly inelegant, albeit for completely different reasons than the above -- for me, it's the fact that dpkg will subsequently lie to me about the contents of said package. If I do a dpkg -L <packagename>, I expect it to tell me what files that package needs, and if another package attempts to overwrite one of them, I expect to be warned. This is sufficiently important to me that I have never used an installer package on my own system -- I build my own packages myself if I have to, or I install in /usr/local until I can find the time. At the same time that I say this, I will also say that I do not believe this statement reflects poorly on your competence or intelligence. What you have done follows a long and time-honored tradition of how to deal with packages so non-free that they cannot be distributed directly, and with an attentive maintainer this has worked fairly well in allowing users to use the Debian package upgrade system to keep up-to-date with the upstream package, and as you have noted, it has done so for several years without serious objection. This, however, does not mean that your solution is the optimal one, merely that it achieves its primary objective. Pointing out that it has apparant flaws that make it suboptimal or "broken" should not be immediately construed as insult, if Manoj will forgive me for speaking for him here, I do not believe that is what he intended. I have been playing with the idea of package generators for over a year now, and have gotten a little more serious now that I'm personally dealing with a package that I cannot distribute (vice-roms). Some of my ideas on them are below. > Joey> You raise some valid points as well. Then, without even giving > Joey> me a chance to respond, you raise the specter of _forking_ my > Joey> work ("I'll probably steal your code"), and introducing a > Joey> duplicate package into Debian, which will only serve to confuse > Joey> users. Who is threatening whom again? If the description lines are sufficiently descriptive, it doesn't have to be too confusing to users. My own design called for <package>-gen, which creates <package>. Using realplayer as an example, the package I would upload to Debian would be called realplayer-gen, and could in fact sit next to your realplayer package, with the explanation that it allows for the creation of a package that properly tracks all files, as opposed to an installer package doesn't, but has the ability to install a working package in one pass, instead of requiring moderate user interaction to create a package that then has to be installed with dpkg instead of apt. The realplayer package created by realplayer-gen could in fact be a drop-in replacement for the Debian realplayer package, except that if you continue to maintain your package apt will spontaneously attempt to upgrade in a way that would probably be confusing to even the sort of user that uses a -gen. The primary disadvantage to my system is that dpkg cannot be called recursively, and so there will always be at least one extra step (I think I could even handle downloading and package generation in a postinst if I had to, though that would of course negate some of its advantage to people like Manoj) required before a final updated working package could be installed, and if one was used to upgrading lots of packages at once, it could be missed that the real package still needed to be installed by hand. Skipping down to Manoj's response... > And what I said was if you find the design I proposed to be > unacceptable as a maintainer, which is your right, then I'll fork the > package. Why on earth do you look upon a fork (espescially of a > package you claim never to have liked maintaing, and one you were > planning to orphan anyway) as a threat? ... this is *exactly* the kind of thing where a fork would be useful, especially a coordinated one. Ideally, in my mind, I see a policy proposal being written to accompany this, that all installer packages should take the naming convention <packagename>-inst, and all generator packages take the naming convention <packagename>-gen, with the actual packagename being left free not only for generated packages, but for people building their own (I've gotten around being automatically upgraded by slamming an ugly epoch into my own builds, but ideally this shouldn't be necessary). Some people will prefer to use the one-pass -inst style of packages, and some people will prefer to use a -gen (I'd be one of them) -- especially since a -gen, properly observed on the user end, offers the same ability to keep a a package in sync with an upstream version -- you just have to do the last install step by hand every time you see it get upgraded by apt. People that are bothered by this would be better off with an -inst, provided there were maintainers interested in each style of packaging. > And if you seriously are offended by people reusing your code, > you are supporting the wrond software development process in > Debian. (I can't honestly believe you are upset about someone > ``stealing your code'', so this is either heat of the moment, or pure > rhetoric). And since I have already entered onto shaky footing by presuming to speak for Manoj, let me stick both feet in and beg forgiveness from Joey for doing so for him, but I'm pretty sure this isn't what he was objecting to. From his response, I got the sense that it's not the reuse of code, but the implicit appearance of hijacking his package without consulting with him on the matter and thereby demeaning his work. > I am surprised. This is the last place I expected to find > people bothersd by code ``stealing''. Fine. I'll not use any code you And your willingness to assume this absurdity from a source as unlikely as Joey isn't helping, either. Please consider in the future that when someone says something unbelievable, there may be a miscommunication in progress. > Joey> Then you compound these insults by demanding that I rename my > Joey> package, which has 3 years of prior art, to make way for your > Joey> vaporware. > > Your package is misnamed. It is not realplayer, it is a > realplayer installer. A real .deb realplayer binary has better claim > to the name realplayer. I am sorry if that is not as obvious to you > as it appears to be to me. I agree with Manoj on this, too. The practice of naming installer packages as if they actually contained the files they were installing has bothered me since I first noticed it, since it prevents users from creating logically-named local packages. However, a request for name-coordination on a package should not be considered an insult. Although some confusion always results from a name change, a structure set down now could prevent future confusions (and thus I would be happy to see a policy amendment on the matter, even if it isn't needed specifically for this case due to complete abandonment of realplayer -- if I find time I may write one myself), and certainly there have been package name conflicts in the past that were settled more or less amiably. > Joey> I hope you might have a glimmering of an idea now about why I'm upset. > Joey> I hope _someone_ enjoys maintaining realplayer; I never have. And I > Joey> sincerely hope it's not you. > > Why, Thank You, kind sir. Rest assured the bug-promise has > ensured that shall never happen. Well, if these decisions haven't been set in stone yet, I'd like to propose a couple of solutions to this. First, that unless my reasoning on the viability of coexistence of these -inst and -gen is completely off, you two could work together to split the work involved in maintaining a realplayer package more or less as Manoj has proposed, or if one side feels it must abandon the package completely to the maintenance of the other, that whoever picks up the package maintain both structures. The simplest way of handling this would be to have a realplayer source package create realplayer-inst and realplayer-gen, since the changes will come primarily from changes in upstream location, and shouldn't be too hard to track. Manoj, since you were willing to heavily draw upon Joey's code before, why not simply keep *all* of it in place, and add your own separate structure? You get your new kind of package, Joey and fans of his method get their automatically updated version, at the cost of a slight increase in maintenance work and short-term grumbling over a package renaming. Joey, if either Manoj or I provided you with code to create a -gen package, would you be willing to maintain it next to your installer? Would you be willing to go along with a one-time package renaming, especially if one of us could write a policy proposal organizing this sort of thing for the future? -- Zed Pobre <firstname.lastname@example.org> a.k.a. Zed Pobre <email@example.com> PGP key and fingerprint available on finger; encrypted mail welcomed.
Description: PGP signature