On Wed, 20 Jun 2012 16:25:30 -0400
Richard Yao <ryao@gentoo.org> wrote:
> Multilib (and/or multiarch) support
> The current binaries cause a great deal of pain, particularly
> when a user does not want to upgrade something. I had this problem
> with WINE and glibc because I wanted to avoid the reverse memcpy()
> fiasco on my systems. This situation would have been avoided entirely
> if the package manager supported multilib.
This one's unlikely to happen unless someone's prepared to put in the
work.
> POSIX Shell compliance
> There has been a great deal of work done to give the user
> full control of what is on his system and there is more that we can
> do there. In particular, I think a lean Gentoo Linux system should be
> able to use busybox sh and nothing else. That requires POSIX shell
> compliance. OpenRC init scripts support this and the configure
> scripts support this. The few exceptions are bugs that are addressed
> by the Gentoo BSD developers. As such, I think we should make EAPI=5
> use POSIX shell by default. If an ebuild requires bash, we can allow
> the ebuild to declare that (e.g. WANT_SH=bash), but that should be
> the exception and not the rule.
So far as I know, every PM relies heavily upon bash anyway (and can't
easily be made not to), so even if developers would accept having to
rewrite all their eclasses, it still wouldn't remove the dep.
--
Ciaran McCreesh
06-20-2012, 08:39 PM
Maxim Kammerer
My wishlist for EAPI 5
On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao <ryao@gentoo.org> wrote:
> Multilib (and/or multiarch) support
Sorry for a possibly ignorant question. Does multilib support include
the ability to build Busybox against uclibc (on a glibc system)?
On Wed, 20 Jun 2012 23:39:42 +0300
Maxim Kammerer <mk@dee.su> wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao <ryao@gentoo.org> wrote:
> > Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
Nobody knows, since everyone you ask has a different idea of what
multilib is.
--
Ciaran McCreesh
06-20-2012, 08:50 PM
Richard Yao
My wishlist for EAPI 5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org>
> wrote:
>> Multilib (and/or multiarch) support The current binaries cause a
>> great deal of pain, particularly when a user does not want to
>> upgrade something. I had this problem with WINE and glibc because
>> I wanted to avoid the reverse memcpy() fiasco on my systems. This
>> situation would have been avoided entirely if the package manager
>> supported multilib.
>
> This one's unlikely to happen unless someone's prepared to put in
> the work.
The multilib-portage overlay already has this working.
>> POSIX Shell compliance There has been a great deal of work done
>> to give the user full control of what is on his system and there
>> is more that we can do there. In particular, I think a lean
>> Gentoo Linux system should be able to use busybox sh and nothing
>> else. That requires POSIX shell compliance. OpenRC init scripts
>> support this and the configure scripts support this. The few
>> exceptions are bugs that are addressed by the Gentoo BSD
>> developers. As such, I think we should make EAPI=5 use POSIX
>> shell by default. If an ebuild requires bash, we can allow the
>> ebuild to declare that (e.g. WANT_SH=bash), but that should be
>> the exception and not the rule.
>
> So far as I know, every PM relies heavily upon bash anyway (and
> can't easily be made not to), so even if developers would accept
> having to rewrite all their eclasses, it still wouldn't remove the
> dep.
>
Lets address POSIX compliance in the ebuilds first. Then we can deal
with the package managers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 06/20/2012 04:39 PM, Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao <ryao@gentoo.org> wrote:
>> Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?
It includes it no more than portage does currently.
06-20-2012, 08:52 PM
Luca Barbato
My wishlist for EAPI 5
On 06/20/2012 10:25 PM, Richard Yao wrote:
> Here is my wishlist for EAPI 5:
>
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
>
> Here are some explanations:
>
> Multilib (and/or multiarch) support
> The current binaries cause a great deal of pain, particularly when a
> user does not want to upgrade something. I had this problem with WINE
> and glibc because I wanted to avoid the reverse memcpy() fiasco on my
> systems. This situation would have been avoided entirely if the package
> manager supported multilib.
>
> Automated epatch_user support
> Users should be able to test patches without modifying their ebuilds.
> This also saves developer time because we don't need to navigate the
> portage tree (or an overlay), make a change and test it. We could just
> dump the patch in the appropriate directory and build.
>
> Parallel make checks
> As it stands, `make check` is so slow that few people actually run it
> and QA suffers as a result. We have the ability to do parallel checks,
> but we need to explicitly put `emake check` into the ebuild and use
> autoconf 1.12 to get that. It would be best if this behavior were the
> default, not the exception.
>
> POSIX Shell compliance
> There has been a great deal of work done to give the user full control
> of what is on his system and there is more that we can do there. In
> particular, I think a lean Gentoo Linux system should be able to use
> busybox sh and nothing else. That requires POSIX shell compliance.
> OpenRC init scripts support this and the configure scripts support this.
> The few exceptions are bugs that are addressed by the Gentoo BSD developers.
> As such, I think we should make EAPI=5 use POSIX shell by default. If
> an ebuild requires bash, we can allow the ebuild to declare that (e.g.
> WANT_SH=bash), but that should be the exception and not the rule.
It is more likely to succeed either adding to busybox the missing bits
of bash we use or forking bash (so eventually it could be developed on a
source repo) and making it lean and fast for our specific purposes.
On Wed, 20 Jun 2012 16:50:33 -0400
Richard Yao <ryao@gentoo.org> wrote:
> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org>
> > wrote:
> >> Multilib (and/or multiarch) support The current binaries cause a
> >> great deal of pain, particularly when a user does not want to
> >> upgrade something. I had this problem with WINE and glibc because
> >> I wanted to avoid the reverse memcpy() fiasco on my systems. This
> >> situation would have been avoided entirely if the package manager
> >> supported multilib.
> >
> > This one's unlikely to happen unless someone's prepared to put in
> > the work.
>
> The multilib-portage overlay already has this working.
But there is no spec, nor is there a developer-centric description of
it.
> > So far as I know, every PM relies heavily upon bash anyway (and
> > can't easily be made not to), so even if developers would accept
> > having to rewrite all their eclasses, it still wouldn't remove the
> > dep.
>
> Lets address POSIX compliance in the ebuilds first. Then we can deal
> with the package managers.
Why? It's highly doubtful the package manglers could switch shells even
if they wanted to, and even if every ebuild started using EAPI 5. It's
wasted effort.
On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao <ryao@gentoo.org>
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> <ryao@gentoo.org> wrote:
>>>> Multilib (and/or multiarch) support The current binaries
>>>> cause a great deal of pain, particularly when a user does not
>>>> want to upgrade something. I had this problem with WINE and
>>>> glibc because I wanted to avoid the reverse memcpy() fiasco
>>>> on my systems. This situation would have been avoided
>>>> entirely if the package manager supported multilib.
>>>
>>> This one's unlikely to happen unless someone's prepared to put
>>> in the work.
>
>> The multilib-portage overlay already has this working.
>
> But there is no spec, nor is there a developer-centric description
> of it.
>
>>> So far as I know, every PM relies heavily upon bash anyway
>>> (and can't easily be made not to), so even if developers would
>>> accept having to rewrite all their eclasses, it still wouldn't
>>> remove the dep.
>
>> Lets address POSIX compliance in the ebuilds first. Then we can
>> deal with the package managers.
>
> Why? It's highly doubtful the package manglers could switch shells
> even if they wanted to, and even if every ebuild started using EAPI
> 5. It's wasted effort.
>
Source the ebuild using the system shell, check for WANT_SH. If it
does not exist, proceed. If it does, start over with a different shell.
I do not see any technical problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao <ryao@gentoo.org>
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> <ryao@gentoo.org> wrote:
>>>> Multilib (and/or multiarch) support The current binaries
>>>> cause a great deal of pain, particularly when a user does not
>>>> want to upgrade something. I had this problem with WINE and
>>>> glibc because I wanted to avoid the reverse memcpy() fiasco
>>>> on my systems. This situation would have been avoided
>>>> entirely if the package manager supported multilib.
>>>
>>> This one's unlikely to happen unless someone's prepared to put
>>> in the work.
>
>> The multilib-portage overlay already has this working.
>
> But there is no spec, nor is there a developer-centric description
> of it.
I missed this tibbit. I am not sure what you expect me to do this
about this. Thomas Sachau developed the multilib overlay, he has put a
great deal of work into it and he likely has a specification. You are
more than welcome to talk to him about the specification. If it not
well defined, feel free to share your ideas on how it could be better
defined.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On Wed, 20 Jun 2012 17:02:10 -0400
Richard Yao <ryao@gentoo.org> wrote:
> >> Lets address POSIX compliance in the ebuilds first. Then we can
> >> deal with the package managers.
> >
> > Why? It's highly doubtful the package manglers could switch shells
> > even if they wanted to, and even if every ebuild started using EAPI
> > 5. It's wasted effort.
> >
>
> Source the ebuild using the system shell, check for WANT_SH. If it
> does not exist, proceed. If it does, start over with a different
> shell.
>
> I do not see any technical problem.
Package managers don't "source the ebuild"... You should take a look at
the amount of horrible bash code the three PMs have, and see why it's
there.
My wishlist for EAPI 5
