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

[Kent Fredric]

On Thu, 29 Sep 2016 23:56:34 +0200
Andy Mender  wrote:

> I believe the main problem comes from /bin/bash and potential symlinks that
> would need to be introduced as part of  the slotting.

In a pinch you could probably get away with
calling :1 /usr/bin/bash-4.4 instead of /usr/bin/bash, and then
offering no luxuries beyond that, leaving it up to the user to do the rest.

Then you could test it in ~/ with PATH + Symlink in ~/bin/ ... maybe.

There would just not be much point, because the real purpose of testing
4.4 is not for fear of it breaking user experience ( which is a
problem, but not the primary motive ),  but for making everything else
that runs with bash runs OK.

Maybe you could do some horrible QA Violation like USE=multislot
which changes the slot from :0 and adds the -suffix at the same time.

But I still don't think its a useful or good idea.


pgpz1hFyHx4J3.pgp
Description: OpenPGP digital signature

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

[Andy Mender]

Yes, I also wouldn't want to sacrifice something as relevant as the default
Shell interpreter.
I quickly checked other GNU/Linux distributions and even on Arch Linux Bash
4.3 seems to be the newest stable version.

Would it be OK to have the real stable version (now, Bash 4.3) as slot :0
and a single testing version (now, Bash 4.4) as slot:1 in addition to
needing the "~amd64" flag?

I believe the main problem comes from /bin/bash and potential symlinks that
would need to be introduced as part of  the slotting.

Best regards,
Andy

On 29 September 2016 at 07:54, Dan Douglas  wrote:

> The only reason I haven't been testing this for many months
> system-wide is it's in the same slot as 4.3, and it still is. Is it
> not possible to separate them?
>
>

Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS

[Michał Górny]

On Sun, 25 Sep 2016 23:08:52 +0200
Michał Górny  wrote:

> Hi,
> 
> I'd like to introduce a new USE_EXPAND for LLVM & clang. It'd be named
> LLVM_TARGETS, and it's going to replace the current solution based on
> USE=multitarget & VIDEO_CARDS=radeon.
> 
> In the old system, the following rules applied:
> 
> - host (implicitly figured out by LLVM) and BPF targets were always
>   built,
> 
> - VIDEO_CARDS=radeon enabled additional R600 target,
> 
> - USE=multitarget enabled all targets.
> 
> In the new system, LLVM_TARGETS explicitly controls *all* targets
> built. To avoid dependency hell, the host target is package.use.forced
> in specific arch profiles. Additionally, the BPF target is on by
> default.
> 
> The new system will be applied to 3.9.0 and  ebuilds. VIDEO_CARDS
> flag will be removed completely because of no revdeps. USE=multitarget
> will be kept for compatibility until all revdeps are clean.
> 
> As far as revdeps are concerned:
> 
> - Packages that require only host target will not have to be changed at
>   all (since host is still forced-on).
> 
> - Packages that used to require multitarget will eventually have to be
>   changed to request the specific targets they need. They could switch
>   to this when they stop supporting LLVM < 3.9.
> 
> The draft implementation is available in the following PR:
> https://github.com/gentoo/gentoo/pull/2405
> 
> Any comments?

Committed now.

-- 
Best regards,
Michał Górny



pgpxLZEn5Oylu.pgp
Description: OpenPGP digital signature