Re: bsdinstall TUI utility

On Mon, May 30, 2022 at 11:40 AM Devin Teske <dteske@freebsd.org> wrote:

>
>
> On May 30, 2022, at 9:18 AM, Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Mon, May 30, 2022, 9:59 AM Devin Teske <dteske@freebsd.org> wrote:
>
>>
>>
>> > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com>
>> wrote:
>> >
>> > Obviously, I made some mistake writing in English.
>> >
>>
>> No, your English is fine. Perhaps I did not explain myself well.
>>
>>
>>
>> >
>> > Currently, I am working to replace dialog(1) and dialog(3) in BASE with
>> > a BSD licensed alternative <https://wiki.freebsd.org/GPLinBase>.
>> > I have almost completed the task
>> > <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>.
>>
>> Well understood.
>>
>> I have been observing the work.
>>
>>
>> > luckily somebody helped me, I will thank at the end.
>> >
>> >
>> > The topic of the email is not bsdconfig.
>>
>> Also understood.
>>
>>
>>
>>
>> > It has already a review,
>>
>> Link?
>>
>>
>>
>> > it preserves the $DIALOG variable to handle a multitude of front-end:
>> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on.
>>
>> Good.
>>
>>
>>
>> > I would continue the discussion for bsdconfig in phabricator;
>> > although I should update it after some recent commit.
>> > <https://reviews.freebsd.org/D34755>.
>> >
>>
>> I have commented that I request time to review.
>>
>>
>>
>> >
>> > The topic of this email is bsdinstall.
>>
>> Correct.
>>
>>
>>
>> > I have to update the last few
>> > scripts to delete LGPL-dialog from BASE. Properly I asked the right way
>> > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts because
>> > the others used only and called directly `dialog` without any
>> > bsdconfig's help.
>> >
>>
>> When you look at the bsdinstall code and you see that it calls dialog
>> without bsdconfig’s help, that is because I have not written the code yet.
>> When I am done with bsdinstall, it will use bsdconfig’s API (see “bsdconfig
>> api”)
>>
>> So removing it will only see it added again later.
>>
>>
>>
>> >
>> > On 5/29/22 01:02, 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?
>> > >
>> >
>> > OK.
>> >
>> > >
>> > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility.
>> > >
>> > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG
>> >
>> >
>> > Exactly 1.
>> >
>> >
>> > >
>> > > 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
>> > >
>> >
>> >
>> > Exactly 2.
>> >
>> >
>> > >
>> > >> 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
>> >
>> >
>> > Exactly 3.
>> >
>> >
>> > Anyway, probably the misunderstanding is at this point. My question is
>> > not for bsdconfig but for 4 scripts in bsdinstall.
>>
>> No, the confusion is that I have my own roadmap that includes fixing
>> namespace issues in bsdinstall before then merging bsdinstall with
>> bsdconfig so that they use a single API.
>>
>
> Any chance we could unify the efforts?
>
> As the code I previously linked to in GitHub demonstrates, I was working
>> on it in 2020 last, and then the pandemic hit and then I had a child, and
>> then two root canals, and then some issues due to a data breech, so it’s
>> been a very busy couple of years, pandemic aside — at work we only just
>> returned to the office last week and had been entirely remote for over 24
>> months (and to be honest, it is a little strange to come back into the
>> office and find *everything* exactly as it was, even to the point that the
>> fridge is freshly stocked with the same exact foods that were in the fridge
>> the day we closed the office; it’s Twilight Zone levels of freaky).
>>
>>
>> > Let' s say: "should bsdinstall/scripts/auto have the code to handle
>> > $DIALOG/LGPL-dialog/Xdialog"
>> > ```
>> >       if [ "$USE_XDIALOG" ]; then
>> >               yes=ok no=cancel defaultno=default-no
>> >               extra_args="--wrap --left"
>> >               format="$passed_msg"
>> >       else
>> >               yes=yes no=no defaultno=defaultno
>> >               extra_args="--cr-wrap"
>> >               format="$passed_msg"
>> >       fi
>> >
>> >       ...
>> >
>> >       EXTRA_DISTS=$( eval dialog \
>> >                   --backtitle \"$OSNAME Installer\" \
>> >
>> > ```
>> >
>> > Please note, I have not a strong opinion, if you confirm your needs for
>> > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstall
>> > I'll add and preserve these features in the 4 scripts.
>> > Please let me know, so I can complete the dialog/bsddialog replacement
>> > soon.
>> >
>>
>> My answer is YES, the code could continue to handle that for three very
>> simple reasons:
>>
>> 1. The effort of your roadmap is to *introduce* bsdinstall and
>> introduction of something new is easier when remnants of the past can be
>> referenced as we work toward the goal of:
>>
>> 1.a. Reaching parity
>>
>> 1.b. Removing deprecated code
>>
>> 2. Removing old while adding new means if there is ever a discrepancy:
>>
>> 2.a. I have to go to git to see how old code worked
>>
>> 2.b. I have to install old code to run it (opposed to installing old
>> dialog and  setting some environment variables)
>>
>> 3. Making fixes to correct an unintended consequence may introduce issues:
>>
>> 3.a. When I cannot run the head (as described in 2 above) code with old
>> dialog
>>
>> 3.b. … as I have to run two codeines and merge between the two
>>
>> 3.c. … and there will be a time in the future when this should be
>> expected to break and that should trigger removal, but not before
>> completing the transitional period on a roadmap to reach parity
>>
>>
>>
>> >
>> > >
>> > >
>> > >> I would prefer this solution because I can avoid: to handle some
>> > >> dialog/Xdialog/bsddialog command line difference and to hook some
>> > >> bsdconfig function built on dialog(1) incompatible with bsddialog(1)
>> > >> (for example autosizing, implemented in bsddialog(3) already).
>> > >>
>> > >
>> > > The differences in command line should be handled through
>> conditionals, but can be the default and opt to handle LGPL-dialog through
>> a USE_GNU_DIALOG flag
>> > >
>> > > bsddialog may support auto-sizing, but so does dialog and Xdialog.
>> > >
>> > > However, ...
>> > >
>> > > The sizing code in bsdconfig (used indirectly by bsdinstall) was
>> written because the auto-sizing that does exist and is available in both
>> dialog and Xdialog (as well as Zenity) does not provide a cohesive
>> experience when trying to write a program that is in-reality a series of
>> bespoke dialogs.
>> > >
>> > > The sizing code makes sure that regardless of which utility you are
>> using that the experience is uniform in what is presented to the user.
>> > >
>> > > Attempting to rely solely on the auto-sizing available from these
>> separate utilities (including bsddialog) would change the UI/UX.
>> > >
>> > > The problem was solved by:
>> > >
>> > > 1. Making the stored text used for dialogs dictate how it will look
>> > > 2. Painstakingly determining where each utility failed given the text
>> > > 3. Determining how to make the utility display the text properly
>> > >
>> > > For example, stored text will contain newlines instead of attempting
>> to rely on line wrapping on a box of given size.
>> > >
>> > > I would have to evaluate bsddialog’s auto-sizing to determine if it
>> is trust-worthy given not only all the stored texts, but all the
>> translations as well (as bsdconfig is i18n compatible). It is actually less
>> work to just allow bsdconfig to likely treat bsddialog as it is dialog and
>> let it perform the size calculations for you.
>> > >
>> > > If bsddialog is top be a drop-in replacement, I’m more than a little
>> surprised that it cannot accept the sizes calculated for dialog being
>> passed to it.
>> > >
>> > >
>> > >>
>> > >> Please note these considerations are only for bsdinstall, bsdconfig
>> is
>> > >> unchanged.
>> > >>
>> > >
>> > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-turn
>> relies on dlg_gauge_reallocate(3) from LGPL-dialog?
>> >
>> >
>> >
>> > I seem these considerations are for bsdconfig so the discussion can
>> > continue in phabricator. Of course I made some error in English in the
>> > first email.
>>
>> No, your English was fine. I perhaps did not explain the we are at
>> perhaps cross efforts with our distinctly separate roadmaps with their own
>> goals and timelines.
>>
>>
>>
>> >
>> > Here the topic is bsdinstall.
>> >
>> > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months,
>> > all the components (written in C) were adapted or rewritten to
>> > use bsddialog(3). Example
>> >
>> https://cgit.freebsd.org/src/commit/?id=50e244964e9b06528b84720e09da7bdf8cec6d32
>> >
>>
>> I will review and get back with comment.
>>
>>
>> > Most bsdinstall scripts "call" just `dialog` using its autosizing
>> > (without any bsdconfig's  help).
>> > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example
>> >
>> https://cgit.freebsd.org/src/commit/?id=4d1ba6febfa7c7808027fd1ef60b3bffadd17853
>> > The important question was asked above. I would want to understand the
>> > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall
>> > scripts.
>> >
>>
>> Correct. It is part of my roadmap to remove said auto-sizing in
>> bsdinstall.
>>
>>
>>
>> > I had some problem using the autosizing functions of bsdconfig for
>> > bsddialog,
>>
>> I do not fully understand this. The API examines the text and determines
>> the proper size to pass. Can bsddialog not accept a size?
>>
>>
>>
>>
>> > probably bacause dialog(3) and bsddialog(3) implement
>> > different auto text wrapping algorithms, or the utilities have different
>> > command lines.
>>
>> Does bsddialog have support for specifying the size of a widget?
>>
>>
>>
>>
>> > Honestly I am not interested in investigating,
>>
>> That is an unfortunate statement. I am interested in the work being done,
>> perhaps you could be interested in the work I am doing that I have been
>> working on for longer than you have been working on bsddialog.
>>
>>
>>
>> > I would
>> > like to improve bsddialog instead of wasting time on a LGPL software
>> > almost ready to leave the BASE.
>>
>> Leaving existing code in place does not waste time on LGPL software
>> because:
>>
>> 1. Someone like myself will be installing LGPL dialog from ports and
>> relying on the old code to utilize it:
>>
>> 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using
>> environment variables) between LGPL dialog and bsdialog
>>
>> 1.b. so that I can compare the two against each other and fix any
>> regressions
>>
>> Removing the code to handle LGPL dialog at the same time as removing LGPL
>> dialog from base kind of makes that hard. As previously explained, that
>> will force me to perform a series of hacks where I pull down the old tree
>> with the LGPL handling code and make changes blindly which will only become
>> more and more difficult as the old code without bsddialog support and new
>> code (as you propose) without LGPL handling code drift further and further
>> apart.
>>
>> I don’t understand what is so difficult about separating the task of
>> “adding support” and “removing deprecated features” to accommodate a
>> transitional period is so difficult — it makes reaching feature parity
>> (which is in bsddialog’s interest) very difficult if you try and do both of
>> those things at the same time.
>>
>>
>>
>> > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in
>> > bsddialog(3) with colors, a callback and bottom info" depending only on
>> > BSD licensed code.
>>
>> Cool!
>>
>>
>>
>> > The complete unicode support is a TODO, although bsddialog provides some
>> > feature already https://bugs.freebsd.org/248968
>> >
>>
>> Interesting. Will have a look.
>>
>>
>> > This is probably another misunderstanding. My goal, after some email and
>> > chat with others, is to provide a BSD licensed alternative to dialog
>> > for the "BASE needs"; similar not equal, otherwise the effort would not
>> > be feasible for a single.
>> > Indeed, also the command lines are quite different. Example
>> >
>> https://cgit.freebsd.org/src/commit/?id=6833ac673d98275ef72a8873372714011c73eb15
>> >
>>
>> Well, let’s *add* support (leaving LGPL dialog code in-place for
>> transitional period, to come back later and remove old, obsolete/deprecated
>> code referring to LGPL dialog).
>>
>>
>>
>> > So far the replacement process was in phabricator with author(s),
>> > maintainer(s) and 2/3 members of the core team. Anyone interested can
>> > notify me to be added in future reviews.
>> >
>>
>> I shouldn’t need notification as a principled author/maintainer.
>>
>
> I've found that having a herald rule in phabricator facilitates this. While
> you are listed in the MAINTAINERs file, it's use has been falling out
> of fashion in the years since we've adopted phabricator. Also, you've
> been kinda AWOL for the last couple of years with activity trailing off
> in the 2018 or 2019 time frame, so it's an understandable, though now
> corrected, oversight. 3 or 4 years is a long time in 'project time' to be
> away
> from the caretaking of things.
>
>
> I was not AWOL. I was (and am) working on my roadmaps.
>

I meant was that there aren't many commits in the last 3-4 years for
bsdinstall
that were authored by you, but there were a large number authored by
others. It
was a way of explaining why people might have thought the entry in
MAINTAINERS
was stale. It was a poor choice of words, and implied much more than I'd
intended.
It was a sloppy shortcut in expressing this. I'm sorry.

Bsdconfig is over 30,000 lines of code. It wasn’t written in a day.
>
> I have 5 large projects I am working on:
>
> 1. Bsdinstall namespace
> 2. Bsdconfig zenity
> 3. libfigput
> 4. Sysconf
> 5. cmb
>
> I am working on them in GitHub instead of an f.o branch because I have
> never been shown how.
>

Great! That's the new model. It's easier for the project to setup, but it
makes
it harder for people to see progress on. there's not been a lot about these
things
on the mailing lists, but they all sound interesting.

Regardless, consider this my notification to be added to add future reviews.
>>
>
> You'll find you are happier if you add the herald rule yourself. It's a
> bit hidden,
> but if you go to reviews.freebsd.org and click on the "More Applications"
> button
> on the left you'll be able to scroll down to find Herald. It makes it so
> people
> don't have to remember, and you'll see everything relevant to the path of
> the
> tree that you register. Obviously people should remember, but this will
> also
> catch new people that are interested in contributing that haven't seen
> this thread.
>
>
> Thanks. Didn’t know MAINTAINERS was on the way out. Will look into Herald
>

Sure thing. It's quite helpful.

Warner


>
>
> I am available again for review — though with a child, it may take some
>> days before I can respond, since I am new to being a parent.
>>
>
> Good luck with your child. They are a joy, but can also take up a lot of
> time.
> One of the hardest lessons I learned when I had my child was that sometimes
> you don't have enough time to influence things as much as you'd have done
> before the child and that things in the project will continue to happen
> nonetheless.
> The shared nature of FreeBSD allows for these transitions, and the passing
> of
> code from hand to hand sometimes since there are no 'hard locks' anymore.
>
>
> Thanks.
>
> I have a non-working spouse, so theoretically only part of what you said
> applies.
>