Re: BoCon - when ? <!-- s/Bo/Bi/ -->

[Mohammed Elzubeir <elzubeir at arabeyes dot org>]

On Mon, 2004-03-29 at 21:48, Muhammad Alkarouri wrote:
> On ن, 2004-03-29 at 07:18, Behdad Esfahbod wrote:
> > On Mon, 29 Mar 2004, Mohammed Elzubeir wrote:
> > 
> > > I recommend instead of having bicon and abicon, having bicon.bin and
> > > bicon respectively. I think that would help settle the confusion (and
> > > have seen it done by various other projects).
> > 
> > Well, I'm thinking something different:  bicon is something that
> > almost works in all terminals, while abicon is console specific.
> > 
> 
> Second that; bicon _will_ be used and also abicon, so I don't  like the
> bicon.bin name.
> 

You can hate the bicon.bin, but abicon makes no sense ;) The 'a' has no
meaning. You want to call it cbicon or whatever, that's fine, but the
'a' has no significance and only serves to confuse.


> The utilities are already compiled; we need just to change the noinst
> and a little tweaking. We need to revise the scripts.
> I don't like to release them with a temporary name, though. Any
> suggestions?
> 

Not sure.
 
> 
> I am not sure about the 'bicontty' name; it gives me a feeling of
> agetty/mingetty/etc. Is it a full replacement for them?
> 

Heh.. yeah, a little too low-level sounding ;)

> I would suggest, in that order: bicondo, biconsole, bcon, bycon.
> As an aside, I will remove the bin/bicon script. Any comments?
> 

I am generally not in favor of funky looking names and would rather see
names that make sense (practicality). I think the current script does
nothing useful at the moment (Persian specific, no? -- I haven't looked
at the code in awhile).

> > 
> > I only meant to do that in a portable way.  Perhaps we can leave
> > it for now, but adding configure parameters for them is what I
> > see a clean solution.  Guess there are parameters for that
> > already.  RPM invokes ./configure with a myriad of parameters.  I
> > will check later, no stopper for now.
> > 
> 
> Leave this for now. I think the proper location should be specified by
> package creators, till keymaps and fonts find their way upstream.
> 

Yes, simply a clear INSTALL file explaining the issue will do. This will
automatically mean that many people will not be able to use it (rarely
do people read the documentation). However, if we can get an RPM package
to accompany the first release, it would help a great deal (and possibly
a deb?).

Regards,
Mohammed Elzubeir