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 <zed@debian.org> a.k.a. Zed Pobre <zed@resonant.org>
PGP key and fingerprint available on finger; encrypted mail welcomed.
Attachment:
pgp1bNR0DdcuE.pgp
Description: PGP signature