Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Sun, Oct 2, 2016 at 7:42 PM, Kent Fredric <kentnl@g.o> wrote:
> On Sun, 2 Oct 2016 18:18:17 +0800
> konsolebox <konsolebox@×××××.com> wrote:
>
>> I should also add that a dynamic "default" that varies depending on
>> the version doesn't sound good to me. For one at least, it confuses
>> the user.
>
> I agree that its a bit unintuitive.
>
> However, the alternatives are:
>
> - A useflag that entirely goes away depending on the version
> - A useflag that is inoperative depending on the version
>
> Neither of those are improvements.

"A useflag that entirely goes away depending on the version" (or a
flag that is implemented in one ebuild but is not on another) is
pretty common among packages and I see that as totally valid, and is
way better than a solution that uses dynamic default.

> And in both cases they're additionally messy as they require
> additional logic that changes what DEPEND is based on the version.

Doesn't look so messy to me.  My solution is pretty clean and
understandable.  It would only depend on how it is perceived by the
reading coder.  The bash ebuild was also already hacky enough.  Maybe
you're just being conservative because it doesn't always happen in
ebuilds.

>> Also, do you think there could be a helpful case that one would
>> install a non-release version of bash that compiles against the system
>> readline?  Perhaps if you're also brave enough to install an
>> pre-release version of readline to the system, there is.
>
> If this scenario was the expected scenario for non-rc releases, its only
> sensible that the development versions should be testing that usecase.
>
> If for example the development versions always only tested using their bundled
> readlines, and then the non-development versions always used dependencies,
> then testing is somewhat pointless.

Pointless for bash, or applications that depend on readline as well?
Because if it's only about bash, I see no difference.

If someone would want to try a pre-release readline, nothing would
stop him from doing it.

> Because you're no longer testing for real world problems that would be possible
> due to using systemized dependenices.( ie: stipulating a new enough version,
> incompatibilities due to gentoo patching, etc )

If some maintainer would really want a pre-release bash tested against
an external pre-release readline, he's free to modify the ebuild to
work that way - just like how he uses to.  We can even add an internal
non-importing custom variable so this could be easily configured.  But
I don't think it's necessary to allow end-users to have that kind of
feature as well.

> "don't use external readline" would have to be the default of bash and
> everyone would have to be being encouraged to be using it that way in order
> for making the testing of that combination also a default.

Ok I don't -really- see that as a bad alternative.  The only question
is, would everyone want that?  And it still doesn't avoid the issue of
users not being able to make 'system-readline' only apply to release
versions of bash, once they enable it globally.

> Otherwise you're testing a situation that will never be a reality.

The difference in our view is whether we should allow users to test if
a -pre-release- bash would link and run well against a pre-release
readline, or not.  That really isn't something to be concerned of, if
you consider that release versions would be tested anyway.  Getting
those will-link-or-not-and-run-properly cases for pre-release versions
tested by developers should be enough.

--
konsolebox