Date: Mon, 30 May 2022 10:49:49 -0700 From: Devin Teske <dteske@freebsd.org> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: "Alfonso S. Siciliano" <alfix86@gmail.com>, freebsd-arch@freebsd.org Subject: Re: bsdinstall TUI utility Message-ID: <052BBC3F-DF35-41E4-9B5A-819A1E9DCEC8@freebsd.org> In-Reply-To: <20220530095815.lznjl6m72yttwadg@aniel.nours.eu> References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <20220530095815.lznjl6m72yttwadg@aniel.nours.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 30, 2022, at 2:58 AM, Baptiste Daroussin <bapt@FreeBSD.org> = wrote: >=20 > On Sat, May 28, 2022 at 04:02:51PM -0700, Devin Teske wrote: >>=20 >>=20 >>> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano = <alfix86@gmail.com> wrote: >>>=20 >>> Hello, >>>=20 >>>=20 >>> So far I replaced and adapted `dialog` with `bsddialog` in >>> bsdinstall/scripts. >>> <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>; >>>=20 >>>=20 >>> 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`. >>>=20 >>=20 >> Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog? >>=20 >>=20 >>> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. >>=20 >> bsdinstall(8) uses only dialog(1) in the context of $DIALOG >>=20 >> ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) >>=20 >>=20 >>> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, >>> Xdialog(1) is not used in this context (that is `bsdconfig -X`). >>>=20 >>=20 >> Correct, bsdconfig does use bsdinstall >>=20 >>=20 >>> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to >>> provide only the support for bsddialog(1) in bsdinstall(8)? >>>=20 >>=20 >> I object. >>=20 >> I and another developer are adding support for zenity >>=20 >> = https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfi= g = <https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconf= ig> >>=20 >> There is also work to resolve the namespace issues in bsdinstall >>=20 >> = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdc= onfig = <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsd= config> >>=20 >> I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it = exists until those efforts can be completed. >>=20 >> ASIDE: bsdinstall doesn=E2=80=99t use Xdialog >=20 > 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=E2=80=99t been =E2=80=9Ctouched =E2=80=A6 for more than 2 = years=E2=80=9D 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=E2=80=99t 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. >=20 I=E2=80=99m 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 =E2=80=94= regardless of the removal of dialog from base =E2=80=94 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. >=20 > So to summerize, are the people working on the bsdconfig having time = to help Yes. I am not the only maintainer =E2=80=94 I have another developer = that I have been working with for over 2 years on our existing roadmap = in GitHub =E2=80=94 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. =E2=80=94=20 Kindest regards, Devin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?052BBC3F-DF35-41E4-9B5A-819A1E9DCEC8>