Re: A proposal for Midnight Commander

[Pavel Roskin <proski gnu org>]

Hello!

I'm afraid I'll not be able to participate in this discussion until
Monday, but let me reply to the last message in the thread.

On Fri, 14 Nov 2003, Alexander Varakin wrote:

> > > The remaining 30% of mc's glib code usage must be the list code, and I
> think
> > > the best way to handle it is just to use glib's implementation.
> >
> > The problem is wasting the time doing this.
>
> You should not worry about this. If this effort will be supported by
> maintainers of mc , I and Ali will make the changes. It does not look like a
> huge effort, couple of days max.
>
> The real problem is that many potential users try to install or build mc and
> suddenly they realize that this small program requires a third party
> library, maybe many of them. When something like this happens to me, I just
> nuke such program and try to forget about it....

Maybe you should try a distribution with proper package management there
installing a package is just a matter of running apt-get or yum.

I believe we should not consider generic arguments against libraries.
Even if such arguments exist, advantages are known to outweigh the
inconvenience.  Libraries exist, hence they are needed.

There is a specific problem with glib 2.x, which is the fact that it
relies on non-common infrastructure, such as pkg-config.  I have voiced my
concerns about it already.  I believe that pkg-config should have been a
script, not a C program.  I do agree that glib 2.x is unnecessarily hard
to compile on OSes without GNU tools preinstalled.

But since glib 1.2.x is not going away, we can support it.  Thanks to
Miguel's clarification, I believe that glib is a good choice.

> > The focus should be on cleaning up *that* code base, taking advantage
> > of what glib has to offer, rather than introducing more regressions in
> > the code.
>
> For this we have another option, the simplest of all: just include the
> whole glib as part of mc. BTW, we already have one 3rd party library
> (slang) included, and nobody complains about it.

That's certainly an option worth considering.  pkg-config itself includes
glib 1.2.x to make it possible to bootstrap it.  glib 1.2.x is not going
to be developed, so we won't need any mergers or maintenance of the code.

If everybody is happy with it, I think that's the direction we should
follow.

By the way (maybe this should be a separate thread), due to known security
problems in VFS (not that we ever promised that VFS is secure) and data
loss bug in the editor (Ctrl-g) fixed in CVS, I had to move most of the
TODO list to "after 4.6.1".  I'm really disappointed that many "must have"
things have been shifted, but it's the best I can do.

My definite plans before 4.6.1 are to fix the only known crash is the code
(freeing extfs under extfs) and the regression caused by the removal of
tilde expansion from VFS.

The next step will be going trough the submitted patches and applying
those that look safe.  During that period, I'm ready to make large changes
if they are unlikely to destabilize the code.  That includes incorporating
glib.

Then there will be a testing period followed by the 4.6.1 release.

-- 
Regards,
Pavel Roskin