[Pkg-crosswire-devel] Module packaging, distribution, and management

[Eeli Kaikkonen]

Quoting Jonathan Marsden <jmarsden at fastmail.fm>:

> Peter von Kaehne wrote:
>
>>> (1) Your stated inability to see the utility of a single standard
>>> packaging system suggests to me that you are more a part of a
>>> Windows-oriented community that a Linux-oriented one.  Community norms
>>> matter, and should be respected.
>
>> I am using Linux (Debian and later Ubuntu since about 9 years as my only
>> operating system). Personal assumptions should not be on this list.
>
> What assumption?  Note carefully my use of "suggests to me".  That
> remains an accurate statement; I may have received a wrong impression,
> but the statement as written is not an assumption, personal or
> otherwise.  In my own experience (which goes back to 1992 on Linux and
> 1980 or so on mainframes and minis, in case it matters), those who fight
> against using package management schemes are often people coming from
> environments where such tools are not available or not widely used.  I
> simply stated what was suggested to me by your own earlier statements
> (such as "I simply do not see the point").  Apparently you are an
> exception to that.  Thanks for letting me know.
>

He's not an exception, he's the rule. As far as I know most Crosswire
developers are dedicated to Open Source and/or Linux or other free
systems.

I have about 10 years of Linux experience, starting from RedHat with a
simple window manager and command line. Before installing I had to
gather the information about the hardware from the hardware itself and
from Windows because there were no autodetection. When I bought my own
machine I installed only Linux there. I went through university
courses with Linux. Only recently I have had a
Windows on my personal machine, that was because of a job. Otherwise I
have used nothing but OSS on my machine. I have also installed Linux
for several friends. After an old RedHat I have installed and
tested/used at least a Finnish RH variant, Debian, Mandrake, Fedora,
SuSe, Gentoo, Kubuntu, and a BSD. The main distro has been Debian - I
don't remember how many years - though recently I have moved to
Kubuntu. I started Debian from stable, then moved to testing, then
noticed that even it was too slow to keep up with recent software and
moved to unstable and even experimental. I guess I have installed and
reinstalled Debian dozens of times.

In some phase, I don't any more remember when, I noticed BibleTime
because I was a KDE fan (I think I used KDE before 1.0). Several years
later I became a BibleTime developer.

I have also been a small part of the Debian community. You can find my
name or email in some old bug reports, and my name should still be
even inside one debian package.

>> The sole lack of respect shown here is by Debian towards
>
> This sentence was incomplete.  Who or what is Debian not respecting, and
> how?  And if the module manager does respect Debian package management,
> it should already work fine with Debian-packaged Sword modules... right?
>  Since it apparently does not, it must be trying to "do its own thing",
> outside of or ignoring Debian package management entirely.  I submit
> that acting in that way can very reasonably be construed as failing to
> respect community norms (since the Ubuntu community normally uses
> package management!).
>

I don't understand why you think like that. We (meaning several
application developers) have together seen that a distro package
management isn't appropriate for the modules. And remember that I have
seen and used .deb, .rpm, yum, dpkg, apt-get, aptitude, Gentoo etc.
Been there, done that, got the scars to prove it. But you sound like
Debian was the only real system around which everything revolves. Our
software isn't developed for Debian, it's developed for users and for
all systems. It has to work everywhere, so there must be a module
manager which works everywhere. BTW, for some reason there have been no
problems with other distros.
>
> Use of Recommends: or Suggests: is preferable, of course; this current
> issue with the "old" (existing) packages has already been discussed, and
> reasonable solutions have been talked through in some detail already, I
> think?  What you "have all the time" now is not necessarily what you
> will get in future -- providing improved packages is what this team is
> all about!  Let's work together to create them.

Yes, Suggests would be a very good solution if someone wants to
package the modules.

>
> "From" anywhere... but not "to" anywhere?  What exactly is the issue it
> has with modules placed by Debian packages into /usr/share/sword/, which
> is a module location officially recommended by current Sword
> documentation (see the INSTALL file from the sword-1.5.11 tarball)?
> Either the Sword module manager does manage them fine there (without
> workarounds such as someone changing perms by hand on files and
> directories, of course!), or else there is an issue, and it does not in
> fact manage them fine there.  I suspect the latter.

The Sword documentation may be right or wrong. It depends on the
situation. It's written by human beings like us, who also are
Crosswire developers, and we know really well that the Sword
documentation isn't always perfect or even good.

And again, I don't understand you. The *nix systems just work like
that: ordinary users are not super users. Super user installs things
which aren't meant to be changed by ordinary users. With our software
super user can install modules as root and users can't remove it. The
package manager doesn't give any advance to that. But automatically
installing the modules with the sofware breaks the idea because it
installs as super user data which should be user controlled. If the  
admin wants data which is not user controlled he can very well use a  
Sword installer.

>
>>>> It is not data like a game episode (a la Wesnoth).
>
>>> Actually, I think this one is fairly close -- they contain information
>>> in a non-standard data format, data without at least one set of which
>>> the application is useless... this is a pretty good comparison, IMO!  In
>>> what sense are Sword modules "not data"?
>
>> This one is indeed the closest. But it still does not apply.
>
> You make a statement here, without any supporting evidence or comment;
> that is just a bare assertion, which is by definition not persuasive.
> Are you willing to back up your assertion?  Or answer my earlier
> question 'In what sense are Sword modules "not data"?' ?

It may be seen as data, but there is more than one kind of data in the
world of computers. There's no point in arguing over words.

>
>> If the admin installs the modules then there is no difference between
>> apt-get and module manager in accessibility
>
> Really?  Is the admin really commonly running GnomeSword (for example)
> as root?  On Ubuntu?  I would find that very surprising.

No, not commonly. But it's a very good solution for shared data. The
admin can start GnomeSword as root and install modules for all users.
Then he can close GnomeSword.


>
>>> Good use of shared module install locations just makes sense in many
>>> many situations.  Good use of data distribution on CD and DVD also makes
>>> sense sometimes.  Debian/Ubuntu style package management handles both of
>>> these, as well as the more common (in the West) case where individual
>>> users have fast cheap Internet access available to them, and have at
>>> least one PC per user.  Does your suggested approach do as well in each
>>> of these situations?
>
>> Yes it does. You can use a CD, usb stick whatever to install on a all 30
>> PCs' on one central location if you run a server or whatever. The module
>> mamanger will not install on /usr/share/sword only if it does not have
>> the permissions. A competent administrator can sort this.
>
> A competent administrator can install everything from source tarballs,
> too!  But such an admin should not *have* to "sort this", if he has to
> mess with directory perms my hand, then this suggests to me that the
> tool he is using for package management is probably inadequate for the
> task.  Competent sysadmins work with their package management system,
> not against it. (BTW, I've been doing sysadmin/netadmin work in some
> form on Internet-facing production servers running Linux and *BSD since
> about 1994, so this statement comes from ~15 years sysadmin and netadmin
> experience).
>
>> As per default install via Debian these permissions are not there for
>> ordinary users nor should they be there.
>
> Right.  Are you now saying that the Sword module manager fixes them,
> automatically, to your own idea of what they should be, when it needs
> to?  I don't think so.  (Actually, I hope not!).  The admin has to go in
> and tweak perms by hand for that to "work".  That is not something a
> full function package management tool should need, surely.  Many admin
> tools on Ubuntu prompt the user before using sudo when they need
> elevated permissions to to package management and similar tasks; perhaps
> this is how module manager could aproach this kind of thing, too?
>

If you can implement it so that it works in all distros and OS's
(including Windows and Mac), go ahead, and I'll be satisfied.

>> But your solution creates a problem for the single user on his own PC
>> who installs ubuntu  on their onw PC and has suddenly two kinds of
>> modules - module managers and apt-get installed ones - and does not have
>> a clue how to deal with that situation.
>
> (ii) the Sword
> module manager needs to notice that it is running on Debian and use apt
> libraries etc to do its work.  It would also notice RPM and use those
> libs on Fedora/RHEL, etc.  I'm betting you would be unhappy with (i).
> So that leaves (ii).
>

You want to push your way into all distros and systems. It just
doesn't work. If we tell this idea to an rpm packager he will probably
say: "Why bother? there's already a good module manager in the app."

> Actually, (ii) would be a really good solution, but it involves a fair
> amount of work -- are you willing to work towards it?  We'd need to
> start by specifying some enhancements to the current sword module
> management API, get the spec approved, implement it, then put code into
> front ends to use the newly enhanced API... it's doable, but for sure
> not in time for Ubuntu Jaunty.  I suggest we look at that approach as
> the long term way forward; it brings the Sword "module manager" more
> into the Debian/Ubuntu world (and of course would do the same in the RPM
> world, if appropriately specified and implemented).
>

We live in a real world where there's limited number of developers who
have limited amount of time to implement things. The idea of detecting
and using different systems is good in theory but it's not practical.
And what would we gain? An admin could do the same thing that he can
already do, a little bit differently.

>> With ubuntu on the scene this is
>> a serious problem. It creates a constant stream of requests on the
>> mailing lists (and I have to deal with them, not you)
>
> I think you may be confusing one current issue with an old set of Sword
> packages, and the whole use of a package manager??  Single users on
> their own Ubuntu PCs already use apt-managed packages (that is most
> likely how they got hold of GnomeSword itself!) so they already can use
> the existing package management tools, more or less by definition.  So
> going in the opposite direction for one particular set of data packages
> does not seem to me to be a rational response to the set of support
> requests you are experiencing; getting the tool that does not currently
> work well on Ubuntu (the Sword module manager) upgraded to work with
> Ubuntu instead of against it would appear to be worth exploring.

You are again centered around one system. The software has to work as
identically as possible on Debian, Fedora, Windows and Mac. Otherwise
we will get support requests asking "why it doesn't work on Debian".


> Sorry, but I'm not going to read the entire archive of a mailing list to
> weed out the design documentation for one part of its API; we have
> weeks, not years, before the Ubuntu Jaunty deadline, and I'd rather be
> doing packaging work for this team!  Can you provide a somewhat more
> specific pointer, please?  Or are you saying that no such documentation
> exists other than the source code?

It was a bad idea to give a pointer to a mailing list. But it's  
irrelevant anyways. The Sword module manager is badly documented as  
the rest of the Sword API. The API and implementation could be better  
if you ask me. But that's not a problem. The problem is that we use an  
idea which is not compatible with a package manager. You say a package  
manager is better for all and for all situations; we say our idea is  
better for us in this situation.

--Eeli Kaikkonen