Re: bsdinstall TUI utility

> On May 30, 2022, at 2:58 AM, Baptiste Daroussin <bapt@FreeBSD.org> wrote:
> 
> On Sat, May 28, 2022 at 04:02:51PM -0700, Devin Teske wrote:
>> 
>> 
>>> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> So far I replaced and adapted `dialog` with `bsddialog` in
>>> bsdinstall/scripts.
>>> <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>
>>> 
>>> 
>>> Currently, I am addressing the last 4 scripts: auto, bootconfig, keymap,
>>> and wlanconfig. These scripts use also the $DIALOG variable and some
>>> "if" to handle Xdialog(1).
>>> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`.
>>> 
>> 
>> Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bsddialog?
>> 
>> 
>>> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility.
>> 
>> bsdinstall(8) uses only dialog(1) in the context of $DIALOG
>> 
>> ASIDE: It also uses dialog(3) and dpv(3)/dpv(1)
>> 
>> 
>>> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably,
>>> Xdialog(1) is not used in this context (that is `bsdconfig -X`).
>>> 
>> 
>> Correct, bsdconfig does use bsdinstall
>> 
>> 
>>> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to
>>> provide only the support for bsddialog(1) in bsdinstall(8)?
>>> 
>> 
>> I object.
>> 
>> I and another developer are adding support for zenity
>> 
>> https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig <https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig>
>> 
>> There is also work to resolve the namespace issues in bsdinstall
>> 
>> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig>
>> 
>> I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it exists until those efforts can be completed.
>> 
>> ASIDE: bsdinstall doesn’t use Xdialog
> 
> I don't think we should block the replacement of dialog with bsddialog in base,
> based on project which have not been touched at all for more than 2 years.

Nobody is blocking anything, stand down.

They haven’t been “touched … for more than 2 years” because I am working on large changes that cannot be committed piece-meal.



> (I am
> not blaming anyone involved in those project, time flies quickly :( ).

I don’t know what you mean by this.



> In particular considering that X-dialog is a long dead project, which will
> probably get removed from the ports tree soonish, and that dialog(1) and
> dialog(3) are planned to get removed from base.
> 

I’m not sure of the relevance to retaining a transitional period that prevents undue burden on integration efforts.



> Don't get me wrong, I do think that there is a value in support multiple dialog
> like application, but either we have the ongoing project back into active mode
> and work with Alfonso

OK



> to ease the integration of bsddialog,

The easiest path to feature parity is a transitional period where — regardless of the removal of dialog from base — dialog-handling code is retained so that integration is not hampered with a head lacking support that is ever-drifting away from the last-known-good point.





> or we complete the
> switch of bsddialog at the price of breaking other dialog utilities support and
> later on, it will be possible to resume the zenity project (or any other) on top
> of it.
> 
> So to summerize, are the people working on the bsdconfig having time to help

Yes. I am not the only maintainer — I have another developer that I have been working with for over 2 years on our existing roadmap in GitHub — either myself or my unofficial mentee can review changes to bsdconfig.

What the community here seems to be implying is that since there were few-to-no commits on the tree that the code has become defunct when that is far from the truth. The reality is that the code has only received minor changes in the past 3-4 years because:

1. It is stable
2. Like the bsddialog project, we have our silo where are working our roadmap (albeit not in the main f.o git view)


> and/or able to propose a concrete plan on how to integrate easily bsdialog to help
> Alfonso moving forward? if yes then that is the best situation for all, if no, I
> think we should pursue with Alfonso's proposal

I recommended a concrete plan in my last e-mail to Alfonso.

Retain existing LGPL-handling code regardless of removal of dialog(1),dialog(3) from base so that I and my colleagues can have an integration period. As previously explained, removing deprecated code simply because the tool has been removed from base (when an integrator like myself or my colleagues that work on bsdconfig can simply re-install it during the sweetheart integration period) makes it unnecessarily difficult to remediate regressions.
— 
Kindest regards,
Devin