19 11

[alpine-devel] Alpine features and the future

Cág
Details
Message ID
<20170615200132.GA24181@alpine>
Sender timestamp
1497556892
DKIM signature
missing
Download raw message
Apparently there has been some sort of speculation regarding
replacement of some components of the system with others, and
apparently many moons ago last time, at least on this list.
I would like to know Alpine developers' and users' positions on:

1. BusyBox. Does it need a replacement such as sbase/ubase,
The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

2. GNU software. Should it be replaced by analogues? For example,
make with bmake, bc with heirloom bc, bison with byacc, ncurses
with NetBSD curses.

3. gcc/clang

4. OpenRC. Should Alpine switch to an alternative like runit, s6
or svc? Should /sbin/init be sinit?

5. In case of replacing BusyBox with something that lacks an
editor, what would become the default? nvi, vim, neovim, elvis
traditional vi, nano or vis? Or maybe there will be two like
in OpenBSD or a load as in Slackware?

6. What would be the default shell? mksh, pksh or dash? Or maybe
bash?


Thanks

-- 
caóc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<594317E7.2030906@adelielinux.org>
In-Reply-To
<20170615200132.GA24181@alpine> (view parent)
Sender timestamp
1497569255
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/06/17 15:01, Cág wrote:
> Apparently there has been some sort of speculation regarding 
> replacement of some components of the system with others, and 
> apparently many moons ago last time, at least on this list.


- From IRC lately it seems like not much will change, but the goal is to
give users (and other spins) choice.  As the leader of a spin (Adélie,
a desktop distro based on Alpine), I personally like that goal, but I
may be slightly biased :)


> I would like to know Alpine developers' and users' positions on:


Since you ask for users positions as well I will answer the way I
feel.  I am not an Alpine developer, but I am working on my own spin,
so I am a developer of that spin.


> 1. BusyBox. Does it need a replacement such as sbase/ubase, The
> Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?


BusyBox is meh.  It's fine for recovery environments, and to have a
static binary to call in if you break /lib or something (which just
recently happened to me - a bad shell backtick caused me to set
permission 644 on /lib/ld-musl-x86_64.so.1).  I don't think it is
appropriate for user interaction.  It is missing a lot of options that
I use regularly (particularly in things like mv and grep).  We ship
coreutils right now in Adélie because that's the most usable of the
lot, but I have contributed some code to toybox.

Heirloom is a useful project, especially for things like mailx, but
the Toolchest they have is only barely POSIX and tries to make the
compromise between BSD and GNU extensions by implementing neither.
Again, I'm not sure this is appropriate for user interaction.

I haven't tried out sbase yet.  That is on my radar.


> 2. GNU software. Should it be replaced by analogues? For example, 
> make with bmake, bc with heirloom bc, bison with byacc, ncurses 
> with NetBSD curses.


GNU make is used by way too many packages to be replaced with bmake.
If you mean the Alpine tools themselves, abuild's Makefile looks to me
like it is POSIX make and should be usable by any make implementation
available (very possibly even nmake, but that would be silly).  No
real opinion on the others, but we at Adélie do ship mawk instead of
gawk since it is much lighter while still having much more
functionality than BusyBox awk.


> 3. gcc/clang


Using Clang as a system compiler was my mission when I worked in the
Gentoo project, and we made some progress there before I left.  I've
continued that project in my spare time on my own computers (my main
desktop is a weird hybrid of gentoo, a gentoo fork, and LFS, with most
packages compiled by Clang).  There are still a few packages that
require GCC, mostly kernel-based packages like Xen and systemtap.  I
think in general Clang would be usable as a system compiler if it
could be overridden in certain packages with GCC.  Note too that
Clang's support for some architectures is not mature (or even extant)
so it can't be used everywhere.  Of course that makes more maintainer
burden since now you need to maintain Clang and GCC.  But LLVM is
already a thing in Alpine so it isn't much more maintainer burden than
already exists.


> 4. OpenRC. Should Alpine switch to an alternative like runit, s6 or
> svc? Should /sbin/init be sinit?


I think it would be good to have choice.  Some people like OpenRC, and
some people like s6.  Why not let user decide what is best for their
use case?


> 5. In case of replacing BusyBox with something that lacks an 
> editor, what would become the default? nvi, vim, neovim, elvis 
> traditional vi, nano or vis? Or maybe there will be two like in
> OpenBSD or a load as in Slackware?


nvi is probably the lightest one that can still be used.  elvis is
sadly no longer maintained (was my editor of choice for over a
decade), traditional vi is going to confuse people, and neovim seems
to not be stable yet (but I haven't looked in a while, just going by
what I hear).


> 6. What would be the default shell? mksh, pksh or dash? Or maybe 
> bash?


All the developers I have talked to in Alpine have told me that
BusyBox ash (which is basically dash) is the One True /bin/sh for
Alpine.  I can't imagine that changing.


> 
> Thanks


Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZQxfkAAoJEMspy1GSK50UkB4P/2EMSPNdcE6kwmvgDzdzJigO
bqS6zW69LSMozF1P1IIuvOC0Ti58DOGxmpnYBrNxi5DerhydooqpEo0uZwglPP2n
cLKPys+zZ6zMoySAGg03WC/bmqGM7IhQ7kYCwldDyQzJx2q/an0T0Qx2AF4Ng1m0
1cTN4x+jUVcsLO3nqAKQeFNqWR/i3qFgX6V0j0U0BMjrlfRBOHm/SQdAOfBXfaoa
BV5dHz0F3FHIr4GxYBrUi+9sw8N+LrZIinNFH2/+/Gv7+kHARQwOS3j0lhGoARKY
eKQROOJCILYp9fjUQ/Hsd7z2fmsJZe8ypiUTN5ELtk4foIHxObJ+hGwfev9cqq+s
eJfjbvhrypJ1Y+lpOV7kf3TW2bDvx/+BJfybCiMygHfG4zSyiwoNnhA2mUToLPlK
9nc8IhwvUfDinyHOnofWB46PY07yBMxjojUECMY0h6LgIayNJlOpX8472yMvXcuZ
VWhl2oWTtIdWWRRXvyj7vTAJQihe2ZDMAEJpLu+uTuOkFhRxhtrEzyNUzUqkSrM0
YSwY2O1Y+KiOalpodXl0+E5TEhZoxqaDVdnH1nqZO6hNkMPrYI3dLOeHpgKqz87A
bl5VSiulXRKzzFBqhwa/FDdAqBoJCU4sBvZVuCsKNemm88HHNZgO9JXFi96MuwlT
Jgcuw+kBBnrDYSjzUaBu
=IeQe
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Alan Pillay
Details
Message ID
<CAO6-m01mzcjXvNR277Lekke0AweGNifnsCFKHLZKse5uHfZ3+g@mail.gmail.com>
In-Reply-To
<B94B29B1-CA84-4E47-9F36-E6C8AF4E11F4@shiz.me> (view parent)
Sender timestamp
1497574666
DKIM signature
missing
Download raw message
In light of this discussion I remember all participants about the last
thread about (e)udev/mdev replacement.

https://lists.alpinelinux.org/alpine-devel/4955.html
https://lists.alpinelinux.org/alpine-devel/4959.html
https://lists.alpinelinux.org/alpine-devel/4958.html
https://lists.alpinelinux.org/alpine-devel/4957.html




On Thu, Jun 15, 2017 at 8:46 PM, Shiz <hi@shiz.me> wrote:
>
>> On 15 Jun 2017, at 22:01, Cág <ca6c@bitmessage.ch> wrote:
>>
>> Apparently there has been some sort of speculation regarding
>> replacement of some components of the system with others, and
>> apparently many moons ago last time, at least on this list.
>> I would like to know Alpine developers' and users' positions on:
>
> While I may be an Alpine developer by some measures, I’d like to
> emphasise that the following opinions are mine alone and don’t
> necessarily represent Alpine as a project. ;-)
>
>> 1. BusyBox. Does it need a replacement such as sbase/ubase,
>> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?
>
> In my view, busybox is mostly fine and I see no immediate reason to
> replace it by anything else, especially considering its relative
> completeness when compared to e.g. toy box and sbase. I would be
> very much against shipping coreutils by default.
>
>> 2. GNU software. Should it be replaced by analogues? For example,
>> make with bmake, bc with heirloom bc, bison with byacc, ncurses
>> with NetBSD curses.
>
> Similarly, as someone who actually had to package bmake, I don’t
> see it replacing GNU make any time soon, especially considering its
> own bugs and quirks. I have no immediate qualms about packaging or
> shipping by default GNU software in general, just that which is of
> low quality, which I don’t perceive e.g. GNU make to be, at least
> immediately.
>
>> 3. gcc/clang
>
> This is a more interesting question to me as I’ve been working on this
> for a bit. I see avenues for replacing the system compiler and/or
> toolchain with LLVM and elftoolchain-based alternatives, especially
> considering the development effort big corporations like Google and
> Apple are putting into LLVM, also with regards to hardening like
> UBsan and CFI. So for me, this is actually an avenue I’m actively
> exploring and see potential in, yes.
>
>> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
>> or svc? Should /sbin/init be sinit?
>
> Personally, I like OpenRC and see no immediate need to replace
> busybox init with another init. Since busybox is already in our
> base system, if our case is to keep the base system small, busybox
> init should and does suffice generally well.
>
> Replacing OpenRC with something more architecturally competent like
> s6 would be a nice end-goal yes, but my main current issue with s6
> is still its end-user usability. It, like many others in its style,
> has a severe issue with djb-isms that I don’t see either me or our
> end-users quickly adapting to. As discussed before on FOSDEM, if we
> we were to replace our current init system by anything else, at the
> very least support or automated conversion for our current init
> scripts, as well as an end-user compatible set of command line tools
> equivalent to the current rc-service(8)/rc-update(8) would be a
> definite requirement.
>
>> 5. In case of replacing BusyBox with something that lacks an
>> editor, what would become the default? nvi, vim, neovim, elvis
>> traditional vi, nano or vis? Or maybe there will be two like
>> in OpenBSD or a load as in Slackware?
>
> As stated before, I don’t see an immediate need to replace busybox
> so I have no direct opinion on the matter.
>
>> 6. What would be the default shell? mksh, pksh or dash? Or maybe
>> bash?
>
> Personally, I’d prefer a light POSIX-compatible shell (as is in the
> spirit of Alpine) to be the default, meaning bash, zsh and posh as I
> understand it are immediately disqualified. As I have no problems
> with busybox I see no direct reason to replace its ash implementation
> with anything else, but if it were to be I’d probably pick mksh, or
> maybe even posh.
>
>>
>> Thanks
>>
>> --
>> caóc
>
> - Shiz
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Shiz
Details
Message ID
<B94B29B1-CA84-4E47-9F36-E6C8AF4E11F4@shiz.me>
In-Reply-To
<20170615200132.GA24181@alpine> (view parent)
Sender timestamp
1497570376
DKIM signature
missing
Download raw message
> On 15 Jun 2017, at 22:01, Cág <ca6c@bitmessage.ch> wrote:
> 
> Apparently there has been some sort of speculation regarding
> replacement of some components of the system with others, and
> apparently many moons ago last time, at least on this list.
> I would like to know Alpine developers' and users' positions on:

While I may be an Alpine developer by some measures, I’d like to
emphasise that the following opinions are mine alone and don’t
necessarily represent Alpine as a project. ;-)

> 1. BusyBox. Does it need a replacement such as sbase/ubase,
> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

In my view, busybox is mostly fine and I see no immediate reason to
replace it by anything else, especially considering its relative
completeness when compared to e.g. toy box and sbase. I would be
very much against shipping coreutils by default.

> 2. GNU software. Should it be replaced by analogues? For example,
> make with bmake, bc with heirloom bc, bison with byacc, ncurses
> with NetBSD curses.

Similarly, as someone who actually had to package bmake, I don’t
see it replacing GNU make any time soon, especially considering its
own bugs and quirks. I have no immediate qualms about packaging or
shipping by default GNU software in general, just that which is of
low quality, which I don’t perceive e.g. GNU make to be, at least
immediately.

> 3. gcc/clang

This is a more interesting question to me as I’ve been working on this
for a bit. I see avenues for replacing the system compiler and/or
toolchain with LLVM and elftoolchain-based alternatives, especially
considering the development effort big corporations like Google and
Apple are putting into LLVM, also with regards to hardening like
UBsan and CFI. So for me, this is actually an avenue I’m actively
exploring and see potential in, yes.

> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
> or svc? Should /sbin/init be sinit?

Personally, I like OpenRC and see no immediate need to replace
busybox init with another init. Since busybox is already in our
base system, if our case is to keep the base system small, busybox
init should and does suffice generally well.

Replacing OpenRC with something more architecturally competent like
s6 would be a nice end-goal yes, but my main current issue with s6
is still its end-user usability. It, like many others in its style,
has a severe issue with djb-isms that I don’t see either me or our
end-users quickly adapting to. As discussed before on FOSDEM, if we
we were to replace our current init system by anything else, at the
very least support or automated conversion for our current init
scripts, as well as an end-user compatible set of command line tools
equivalent to the current rc-service(8)/rc-update(8) would be a
definite requirement.

> 5. In case of replacing BusyBox with something that lacks an
> editor, what would become the default? nvi, vim, neovim, elvis
> traditional vi, nano or vis? Or maybe there will be two like
> in OpenBSD or a load as in Slackware?

As stated before, I don’t see an immediate need to replace busybox
so I have no direct opinion on the matter.

> 6. What would be the default shell? mksh, pksh or dash? Or maybe
> bash?

Personally, I’d prefer a light POSIX-compatible shell (as is in the
spirit of Alpine) to be the default, meaning bash, zsh and posh as I
understand it are immediately disqualified. As I have no problems
with busybox I see no direct reason to replace its ash implementation
with anything else, but if it were to be I’d probably pick mksh, or
maybe even posh.

> 
> Thanks
> 
> --
> caóc

- Shiz
Alba Pompeo
Details
Message ID
<CAJDAfTCxbnhV75roDMopNbLa70PaHvuenrQYGHQZ69sTsbimBw@mail.gmail.com>
In-Reply-To
<20170616101643.77795057@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1497615736
DKIM signature
missing
Download raw message
Regarding netbsd-curses instead of, sabotage-linux seems to have been
successful with that.
According to them only "a small percentage of apps written for ncurses
poke at internals and need light patching".
And the benefits are huge.
https://github.com/sabotage-linux/netbsd-curses


On Fri, Jun 16, 2017 at 5:16 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> On Thu, 15 Jun 2017 21:01:32 +0100
> Cág <ca6c@bitmessage.ch> wrote:
>
>> Apparently there has been some sort of speculation regarding
>> replacement of some components of the system with others, and
>> apparently many moons ago last time, at least on this list.
>
> Replacing core components requires a signinficant amount of work. Its
> not like we have overflow of resources and look for things to spend our
> time on.
>
> So if we replace core components it needs to justify the time spent on
> it and the risk of break things for users.
>
> In other words, we don't replaces components just because we can.
>
>> I would like to know Alpine developers' and users' positions on:
>>
>> 1. BusyBox. Does it need a replacement such as sbase/ubase,
>> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?
>
> no.
>
>> 2. GNU software. Should it be replaced by analogues? For example,
>> make with bmake, bc with heirloom bc, bison with byacc, ncurses
>> with NetBSD curses.
>
> replacing GNU make is not a goal, specially if it require us to
> refactor Makefiles of 1000+ packages.
>
> we ship both bison and byacc. You are free to use any.
>
> ncurses thoug, I wouldn't mind replace GNU ncurses as I have had some
> issues in the past with it. (Headers got wrong so lots of packages got
> miscompiled). Before replacing ncurses I want be relatively sure that
> it will not break things.
>
>> 3. gcc/clang
>
> Shiz has been working on it and I would not mind replace gcc with clang
> as default compiler.
>
>>
>> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
>> or svc? Should /sbin/init be sinit?
>
> openrc sort of does the job, but i'm not 100% happy with it. I like the
> ideas behind s6 but find it a bit "weird" (due to djb style) and I find
> it bigger than I'd like.
>
>> 5. In case of replacing BusyBox with something that lacks an
>> editor, what would become the default? nvi, vim, neovim, elvis
>> traditional vi, nano or vis? Or maybe there will be two like
>> in OpenBSD or a load as in Slackware?
>>
>> 6. What would be the default shell? mksh, pksh or dash? Or maybe
>> bash?
>
> i don't see any reason to replace busybox.
>
> -nc
>
>>
>>
>> Thanks
>>
>
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20170616101643.77795057@ncopa-desktop.copa.dup.pw>
In-Reply-To
<20170615200132.GA24181@alpine> (view parent)
Sender timestamp
1497601003
DKIM signature
missing
Download raw message
On Thu, 15 Jun 2017 21:01:32 +0100
Cág <ca6c@bitmessage.ch> wrote:

> Apparently there has been some sort of speculation regarding
> replacement of some components of the system with others, and
> apparently many moons ago last time, at least on this list.

Replacing core components requires a signinficant amount of work. Its
not like we have overflow of resources and look for things to spend our
time on.

So if we replace core components it needs to justify the time spent on
it and the risk of break things for users.

In other words, we don't replaces components just because we can.

> I would like to know Alpine developers' and users' positions on:
> 
> 1. BusyBox. Does it need a replacement such as sbase/ubase,
> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

no.

> 2. GNU software. Should it be replaced by analogues? For example,
> make with bmake, bc with heirloom bc, bison with byacc, ncurses
> with NetBSD curses.

replacing GNU make is not a goal, specially if it require us to
refactor Makefiles of 1000+ packages.

we ship both bison and byacc. You are free to use any.

ncurses thoug, I wouldn't mind replace GNU ncurses as I have had some
issues in the past with it. (Headers got wrong so lots of packages got
miscompiled). Before replacing ncurses I want be relatively sure that
it will not break things.

> 3. gcc/clang

Shiz has been working on it and I would not mind replace gcc with clang
as default compiler.

> 
> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
> or svc? Should /sbin/init be sinit?

openrc sort of does the job, but i'm not 100% happy with it. I like the
ideas behind s6 but find it a bit "weird" (due to djb style) and I find
it bigger than I'd like.

> 5. In case of replacing BusyBox with something that lacks an
> editor, what would become the default? nvi, vim, neovim, elvis
> traditional vi, nano or vis? Or maybe there will be two like
> in OpenBSD or a load as in Slackware?
> 
> 6. What would be the default shell? mksh, pksh or dash? Or maybe
> bash?

i don't see any reason to replace busybox.

-nc

> 
> 
> Thanks
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jens Staal
Details
Message ID
<20170616124945.GA602@Krypton.localdomain>
In-Reply-To
<CAJDAfTCxbnhV75roDMopNbLa70PaHvuenrQYGHQZ69sTsbimBw@mail.gmail.com> (view parent)
Sender timestamp
1497617386
DKIM signature
missing
Download raw message
> >
> >> 3. gcc/clang
> >
> > Shiz has been working on it and I would not mind replace gcc with clang
> > as default compiler.


The most interesting thing with the gcc-->clang switch (to me) is the
switch from libstdc++ to libc++.

I made an experimental gentoo stage 4 (including a llvmlinux-patched
kernel) to play around with it, and a gcc-free base system seems to be
completely possible (on x86_64 at least).


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20170616160545.3d409508@ncopa-desktop.copa.dup.pw>
In-Reply-To
<CAJDAfTCxbnhV75roDMopNbLa70PaHvuenrQYGHQZ69sTsbimBw@mail.gmail.com> (view parent)
Sender timestamp
1497621945
DKIM signature
missing
Download raw message
On Fri, 16 Jun 2017 09:22:16 -0300
Alba Pompeo <albapompeo@gmail.com> wrote:

> Regarding netbsd-curses instead of, sabotage-linux seems to have been
> successful with that.
> According to them only "a small percentage of apps written for ncurses
> poke at internals and need light patching".
> And the benefits are huge.
> https://github.com/sabotage-linux/netbsd-curses

The size benefits are appealing.

-nc

> 
> 
> On Fri, Jun 16, 2017 at 5:16 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> > On Thu, 15 Jun 2017 21:01:32 +0100
> > Cág <ca6c@bitmessage.ch> wrote:
> >  
> >> Apparently there has been some sort of speculation regarding
> >> replacement of some components of the system with others, and
> >> apparently many moons ago last time, at least on this list.  
> >
> > Replacing core components requires a signinficant amount of work. Its
> > not like we have overflow of resources and look for things to spend our
> > time on.
> >
> > So if we replace core components it needs to justify the time spent on
> > it and the risk of break things for users.
> >
> > In other words, we don't replaces components just because we can.
> >  
> >> I would like to know Alpine developers' and users' positions on:
> >>
> >> 1. BusyBox. Does it need a replacement such as sbase/ubase,
> >> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?  
> >
> > no.
> >  
> >> 2. GNU software. Should it be replaced by analogues? For example,
> >> make with bmake, bc with heirloom bc, bison with byacc, ncurses
> >> with NetBSD curses.  
> >
> > replacing GNU make is not a goal, specially if it require us to
> > refactor Makefiles of 1000+ packages.
> >
> > we ship both bison and byacc. You are free to use any.
> >
> > ncurses thoug, I wouldn't mind replace GNU ncurses as I have had some
> > issues in the past with it. (Headers got wrong so lots of packages got
> > miscompiled). Before replacing ncurses I want be relatively sure that
> > it will not break things.
> >  
> >> 3. gcc/clang  
> >
> > Shiz has been working on it and I would not mind replace gcc with clang
> > as default compiler.
> >  
> >>
> >> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
> >> or svc? Should /sbin/init be sinit?  
> >
> > openrc sort of does the job, but i'm not 100% happy with it. I like the
> > ideas behind s6 but find it a bit "weird" (due to djb style) and I find
> > it bigger than I'd like.
> >  
> >> 5. In case of replacing BusyBox with something that lacks an
> >> editor, what would become the default? nvi, vim, neovim, elvis
> >> traditional vi, nano or vis? Or maybe there will be two like
> >> in OpenBSD or a load as in Slackware?
> >>
> >> 6. What would be the default shell? mksh, pksh or dash? Or maybe
> >> bash?  
> >
> > i don't see any reason to replace busybox.
> >
> > -nc
> >  
> >>
> >>
> >> Thanks
> >>  
> >
> >
> >
> > ---
> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> > Help:         alpine-devel+help@lists.alpinelinux.org
> > ---
> >  
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Cág
Details
Message ID
<20170616191912.GA6552@alpine>
In-Reply-To
<20170616101643.77795057@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1497640752
DKIM signature
missing
Download raw message
Thanks for the answers.

I'm asking because I have been fine with sbase/ubase, smdev, sdhcp for
quite some time. I like svc; my /bin/sh is a link to /bin/mksh. I've
yet to compile netbsd-curses on Alpine, but I played with it on NetBSD.

I will support any change as long as it fits the scope, or no changes
at all.

Cheers

-- 
caóc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCE4YNyFbkX9WABXwthwX0wRV_6edF-1S7ON3GT4js=Hww@mail.gmail.com>
In-Reply-To
<20170615200132.GA24181@alpine> (view parent)
Sender timestamp
1498108646
DKIM signature
missing
Download raw message
Hi,

On Thu, Jun 15, 2017 at 3:01 PM, Cág <ca6c@bitmessage.ch> wrote:
> Apparently there has been some sort of speculation regarding
> replacement of some components of the system with others, and
> apparently many moons ago last time, at least on this list.

In general our goal is to make it possible to have more choice, while
retaining sensible lightweight defaults where it makes sense.  It is
not likely that we will change any default components, but instead
make more components swappable (as you can already do with coreutils,
shadow, etc.)

Beyond that in these cases, we try to be transparent and collect as
much comment as possible when making major changes to the
distribution.

> I would like to know Alpine developers' and users' positions on:
>
> 1. BusyBox. Does it need a replacement such as sbase/ubase,
> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

For the foreseeable future, BusyBox will likely remain the primary
cornerstone of our base userland.  There are many Alpine developers
who contribute patches to BusyBox to add new features, and generally
speaking we have an excellent working relationship with the BusyBox
maintainers.  So, at least, right now there is no major reason to us
to make any changes here.  We are quite happy with the way things are
going, and how efficiently we can make changes in BusyBox when
necessary.  The only reason right now why we would move away from
BusyBox is if that relationship with upstream were to change in a
major way, but that seems unlikely.

> 2. GNU software. Should it be replaced by analogues? For example,
> make with bmake, bc with heirloom bc, bison with byacc, ncurses
> with NetBSD curses.

The primary argument for switching from GNU software has to do with
the licensing.  We're not license purists.  As long as the software
meets our redistribution guidelines, the license does not matter so
much.  GPLv3 is obviously compliant with our guidelines.

In cases where the GNU software has a higher quality alternative
(byacc vs bison, GNU vs BSD ncurses), we are tending towards using the
option that we feel has the highest code quality, as higher code
quality usually means less security bugs.

> 3. gcc/clang

We already support both GCC and Clang.  There are plans to make the
default system compiler selectable in Alpine 3.7, and we may switch to
Clang in the future to leverage it's Control Flow Integrity features.
This again comes down to what makes operational sense for the
distribution.

> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
> or svc? Should /sbin/init be sinit?

Most likely we are going to switch to using OpenRC's own init in the
future.  In general, while OpenRC is not perfect, it does fit what we
feel is the proper Alpine workflow, while the DJB style tools do not.
If we were to adopt a DJB-style init system such as runit or s6, we
would provide a compatibility layer on top to make it function
similarly to OpenRC.

> 5. In case of replacing BusyBox with something that lacks an
> editor, what would become the default? nvi, vim, neovim, elvis
> traditional vi, nano or vis? Or maybe there will be two like
> in OpenBSD or a load as in Slackware?

As previously mentioned, we are not likely to switch away from BusyBox
for core userspace.  Any replacement of BusyBox would supply an
editor.

> 6. What would be the default shell? mksh, pksh or dash? Or maybe
> bash?

As we have no plans to switch away from BusyBox, I can't say I have
given it much thought.  However, BusyBox ash is basically in the same
family of shells as dash, and our shell scripts assume that /bin/sh is
an ash derivative.  So, most likely, we would use dash.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jens Staal
Details
Message ID
<20170622103640.GA4076@Krypton.localdomain>
In-Reply-To
<CA+T2pCE4YNyFbkX9WABXwthwX0wRV_6edF-1S7ON3GT4js=Hww@mail.gmail.com> (view parent)
Sender timestamp
1498127801
DKIM signature
missing
Download raw message
On Thu, Jun 22, 2017 at 12:17:26AM -0500, William Pitcock wrote:
>
> > 3. gcc/clang
>
> We already support both GCC and Clang.  There are plans to make the
> default system compiler selectable in Alpine 3.7, and we may switch to
> Clang in the future to leverage it's Control Flow Integrity features.
> This again comes down to what makes operational sense for the
> distribution.


Personally, I think the most compelling thing with clang as system
compiler is the use of libc++ as standard c++ library rather than the
gcc libstdc++.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Tmp File
Details
Message ID
<trinity-f63ec3b6-d159-4629-9087-a9a69e51bf18-1498131911309@3capp-mailcom-lxa11>
In-Reply-To
<20170622103640.GA4076@Krypton.localdomain> (view parent)
Sender timestamp
1498131911
DKIM signature
missing
Download raw message
When writing a script a few days ago I noticed BusyBox doesn't have 'paste' which is a pretty standard unix command.
I wonder what else I'll find missing in the future...

My suggestions is to create a toybox-complement. It would install only the commands *not* present on busybox.
Zero intersection.

What do you think?


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCHQ50j+2RLdy6TnppZQcfLkuZob5YNaY5THNZK5qPCF2g@mail.gmail.com>
In-Reply-To
<trinity-f63ec3b6-d159-4629-9087-a9a69e51bf18-1498131911309@3capp-mailcom-lxa11> (view parent)
Sender timestamp
1498159121
DKIM signature
missing
Download raw message
Hello,

On Thu, Jun 22, 2017 at 6:45 AM, Tmp File <tmpfile@mail.com> wrote:
> When writing a script a few days ago I noticed BusyBox doesn't have 'paste' which is a pretty standard unix command.
> I wonder what else I'll find missing in the future...

If you need something added to BusyBox, just send us a patch for it.
Most likely we will be OK with adding it.

> My suggestions is to create a toybox-complement. It would install only the commands *not* present on busybox.
> Zero intersection.

That's interesting, but is there actually anything in toybox that
busybox does not also have?

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<594C6219.1050504@adelielinux.org>
In-Reply-To
<20170622191734.GA1832@alpine> (view parent)
Sender timestamp
1498178073
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/06/17 14:17, Cág wrote:
> William Pitcock wrote:
> 
>> In general our goal is to make it possible to have more choice, 
>> while retaining sensible lightweight defaults where it makes 
>> sense.  It is not likely that we will change any default 
>> components, but instead make more components swappable (as you 
>> can already do with coreutils, shadow, etc.)
> 
> Having options is nice, while now there are 303 packages that 
> depend on BusyBox. Ideally there would be zero since people who 
> would run "apk -i del busybox" probably know what they are doing. 
> It also would be nice to have some kind of warning if they don't.


I am working on a way to make /bin/sh changeable between BusyBox,
dash, bash, and possibly others. If I can manage to do this
successfully, then we would probably change Adélie's copy of abuild.
It would require packages containing shell scripts to depend on some
sort of shell provider, instead of just blindly adding BusyBox as a
dependency.

I'm not entirely clear how we are going to do this yet, but if there
is interest in integrating this work in to Alpine, perhaps we can have
a more full discussion here.


Best to all,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZTGIYAAoJEMspy1GSK50UZWIP/RDStk0dZkcW/3xO+C0tjucb
7aB1rAeBLNA/e3E1SBt3a0eZfBLKWqC/mdJf12K21EXEcbPwfDSTdGMy29WxHAnU
O2HUwZMStSAu6ekqQLtlgJPRITWkv3TyNLi5rGw7idOBQp4+DPNl8VbXq1sai++Y
bZgjHqV9Y/HRtqZgGuI+3zd4pKDtioACOSTNVymTFa2HgHXku9sr+TGTfBWeAOp4
4lHWMEY23RphbHbB9bKBtwyf7dKyHBgjeXDqwCgWkEFbGtUJJvt6ybxq8I7DvIhQ
sCV8UQZIHFcrnruMWNSQgNg0vta4YNOC3OSx3QX35nf+8/ohuiaivx6fhUQxrQEF
QD3Ng2wGKHoJfKM70y9IdkT3W9Y/s95u3JuYOnj7nf6kaPPBTQJklTp553aSloIr
X2U+BZWPt4D7ZFizTIUnxlMpAef6eumVzkqIwDj9R/CMlnIN+GM+JFBXsLv2gQh3
i3yexEup4SPH1Jyw+rurrdmqLYqsOes6rWuKDmAaMijPPbkUxa7MUkcDbIF6qcoG
gm9IMY1DrJuv0mfVMUVnoDfgS3s+Ct34EXPYN1QR94UIoBtnWhoaU/sOEe8LYCF7
FijHmfEYOIoKxQziu9wAjyLJKr8Ad2jHLlZI7pVuF2YaxKwDIrRqntUf8dT5W8AJ
PaYckeiy3mH4s5H5kal5
=cTje
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Cág
Details
Message ID
<20170622191734.GA1832@alpine>
In-Reply-To
<CA+T2pCE4YNyFbkX9WABXwthwX0wRV_6edF-1S7ON3GT4js=Hww@mail.gmail.com> (view parent)
Sender timestamp
1498159054
DKIM signature
missing
Download raw message
William Pitcock wrote:

> In general our goal is to make it possible to have more choice, while
> retaining sensible lightweight defaults where it makes sense.  It is
> not likely that we will change any default components, but instead
> make more components swappable (as you can already do with coreutils,
> shadow, etc.)

Having options is nice, while now there are 303 packages that depend on
BusyBox. Ideally there would be zero since people who would run
"apk -i del busybox" probably know what they are doing. It also would
be nice to have some kind of warning if they don't.

> We are quite happy with the way things are
> going, and how efficiently we can make changes in BusyBox when
> necessary.  The only reason right now why we would move away from
> BusyBox is if that relationship with upstream were to change in a
> major way, but that seems unlikely.
 
My problem with BusyBox is UTF-8. Somewhere it works, somewhere it doesn't
and it's hard to keep an eye on all of the components since there is a
load of them. TODO for Unicode hasn't been updated for seven years now...

> The primary argument for switching from GNU software has to do with
> the licensing.  We're not license purists.  As long as the software
> meets our redistribution guidelines, the license does not matter so
> much.  GPLv3 is obviously compliant with our guidelines.
 
Some consider GNU software bloat[0] and think that it sucks[1],
it pisses others off ("I'd like to interject for a moment...").

I personally don't care about licences (GPL is bureaucratic though).


[0]: http://agunix.org/fqa
[1]: http://suckless.org/sucks/

-- 
caóc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Drew DeVault
Details
Message ID
<20171204203039.GA18601@miku>
In-Reply-To
<20170615200132.GA24181@alpine> (view parent)
Sender timestamp
1512419439
DKIM signature
missing
Download raw message
Sorry for chiming in late on this thread - I have some thoughts and I'd
like to spin the discussion back up.

For context, I had a project to build a Linux distro called agunix, but
I made some early compromises that spun the project into a distro that
wasn't aligned with my initial goals. I recently spun it down and
decided to contribute to Alpine instead. Alpine is the closest to my
design goals among established distros.

>1. BusyBox. Does it need a replacement such as sbase/ubase, 
>The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils? 

In agunix I was shipping busybox+ubase and it worked very well. I think
busybox's mouth is bigger than its stomach; I prefer to use a busybox
where most of the tools are trimmed out and it basically just implements
POSIX utilities. ubase is suckless.org's project (unportable base) to
implement typical Linux userspace tools like mount(8) and login(8) -
basically most of the non-portable tools in man section 8. They're
pretty minimal and the code is quite straightforward.

https://git.suckless.org/ubase/

suckless has also been working on sbase, which implements most of the
utilities specified by POSIX. There's a status page here detailing the
degree of their completion:

https://git.suckless.org/sbase/tree/README

Personally, I would recommend a minimal busybox build plus ubase without
a second thought, and I would recommend cautiously but earnestly
considering sbase+ubase.

I would also recommend just porting shadow over using busybox user
management tooling. I think `useradd` et al has a more Unix design than
`adduser` et al. Thankfully the shadow codebase hasn't yet been
corrupted beyond saving by the broader Linux ecosystem's influence.

>2. GNU software. Should it be replaced by analogues? For example, 
>make with bmake, bc with heirloom bc, bison with byacc, ncurses 
>with NetBSD curses. 

I dislike GNU software because the code is complex and full of
unnecessary and fragile features. Most GNU software is rather bloated,
too.

>3. gcc/clang 

I dislike them both but there's no good alternatives.

>4. OpenRC. Should Alpine switch to an alternative like runit, s6 
>or svc? Should /sbin/init be sinit? 

I had experience with runit on agunix, and I really liked it. To me it
seemed really close to the ideal init system design. The main problem
with it was the codebase, which is pretty awful. I would love to see a
new init project with a similar design and better code, maybe with some
more porcelain service management commands too (the agunix port shipped
with a patch to let you do `sv enable nginx` instead of manually adding
symlinks).

>5. In case of replacing BusyBox with something that lacks an 
>editor, what would become the default? nvi, vim, neovim, elvis 
>traditional vi, nano or vis? Or maybe there will be two like 
>in OpenBSD or a load as in Slackware? 

I'd just do a minimal (static?) vim build and forget about it.

>6. What would be the default shell? mksh, pksh or dash? Or maybe 
>bash? 

dash

I'd like to start sending some patches to realize this. I have a tracker
for things I want to work on for Alpine:

https://todo.sr.ht/~sircmpwn/alpine

I'm going to start with non-controversial changes like adding doas,
ubase, and shadow to aports while we discuess the harder points.

--
Drew DeVault


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<5A25DE1D.6020602@adelielinux.org>
In-Reply-To
<663B8B1D-79B7-42AE-8B25-A76E821FA54D@shiz.me> (view parent)
Sender timestamp
1512431133
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/12/17 17:00, Shiz wrote:
>> On 4 Dec 2017, at 21:30, Drew DeVault <ddevault@vistarmedia.com>
>> wrote: I would also recommend just porting shadow over using
>> busybox user management tooling. I think `useradd` et al has a
>> more Unix design than `adduser` et al. Thankfully the shadow
>> codebase hasn't yet been corrupted beyond saving by the broader
>> Linux ecosystem's influence.
> 
> Definitely agree with this. I am also of the opinion that `useradd`
> and friends seem more commonly used, and it’s a shame to have to
> recommend using the shadow package for everyone that wants to
> either use it themselves or have tooling using it.


The amount of things that are broken by not having `useradd` is
insane.  We ship shadow in base in Adélie anyway, so this isn't too
big of an issue, but what is an issue is that Alpine build scripts
still think `adduser` and `addgroup` are the way to go.  Our builders
don't have busybox so I had to write clumsy shell shims to 'translate'
them.

I can send them to the list if anyone would be interested; normally I
would put a link, but our Git server ENOSPC'd and I'm still trying to
clean up the pieces before bringing the web interface back online.

I could also write wrappers the other way around if Alpine is really
tied to using `adduser` and `addgroup` so that build scripts can use
`useradd` and `groupadd` without a dependency on shadow.

BTW, is there a reason Alpine doesn't ship shadow as a base dep?  Does
Alpine really recommend use of tcb, or is it some other system?  I've
never been able to figure this out and in fact this is why I gave up
trying to deploy Alpine at my last employer.  We used LDAP and I
couldn't for the life of me make Alpine login(1) use it.


> s6 with a porcelain layer still seems very interesting


+1.


Best,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaJd4ZAAoJEMspy1GSK50Uk9EP/2MJEp2JqObs8oTuI5Ehu6/6
VN6e62vIVDgm6EM78/4dEOd7PgDygfcVaEa+LflczP6sgU5rZXpX5mDn5wxb2XaB
iEsJ/esj306UkFIwnph8VU2z8+FdQ8SwcVD3IF++xKAbDHFCayYqt76nt44aNtjt
9/2FaLha9apU/4Vbl8u5+9l57wvxkyLTNlt2IrPWiB6KOyp2Jl450clE1VYYfjlQ
YroEab9klPToft4izScqPhlHc+AiqaiOwxNdKF2ekY3+bOVi73nZHejgibYtE0kj
tJWnb7M1HlSaPOKQ3XIc+cA/QWGNYWkfg8AwtaWnwSz30LpbV8FOKoRf0AoU4FsU
gTV8GQHKSLKbQgObZGVq9bpgsin8dWRcFbfij5P+sNZLg84nCfsCYH1TBjo+Y37d
gLGFrfHBCHWH5qs039lHa9x6U5tlMcBndvkAwd0FSlQDZaNLHDG3x3Jyq0o7BbTD
yGYj1CtW4udF7V9PxnV9r3PIvBu9OmPC/nNXf+3Mf/i4GOCGdS8IqE5FhFbmbtYG
BOz+g+Z95V3ZWaE4K6B4nqOMLWjM+UyJNJkfKaUz0ppDFKWU+IFDbtwbnYwCCElW
KRz/CY/MnOKi0CYEML7ouij4+SOMwjwv0qNAAS4/Xbqf1dt4JnAP/8gPUS3xSike
GfD+idvKvp24NbAzjbmP
=GK//
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Shiz
Details
Message ID
<663B8B1D-79B7-42AE-8B25-A76E821FA54D@shiz.me>
In-Reply-To
<20171204203039.GA18601@miku> (view parent)
Sender timestamp
1512428409
DKIM signature
missing
Download raw message
> On 4 Dec 2017, at 21:30, Drew DeVault <ddevault@vistarmedia.com> wrote:
> 
> Personally, I would recommend a minimal busybox build plus ubase without
> a second thought, and I would recommend cautiously but earnestly
> considering sbase+ubase.

When I played around with sbase around half a year ago, it seemed rather
immature to be frank. I fear a lot, especially in our old build system,
would break with it.

> I would also recommend just porting shadow over using busybox user
> management tooling. I think `useradd` et al has a more Unix design than
> `adduser` et al. Thankfully the shadow codebase hasn't yet been
> corrupted beyond saving by the broader Linux ecosystem's influence.

Definitely agree with this. I am also of the opinion that `useradd` and
friends seem more commonly used, and it’s a shame to have to recommend
using the shadow package for everyone that wants to either use it
themselves or have tooling using it.

>> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
>> or svc? Should /sbin/init be sinit?
> 
> I had experience with runit on agunix, and I really liked it. To me it
> seemed really close to the ideal init system design. The main problem
> with it was the codebase, which is pretty awful. I would love to see a
> new init project with a similar design and better code, maybe with some
> more porcelain service management commands too (the agunix port shipped
> with a patch to let you do `sv enable nginx` instead of manually adding
> symlinks).

s6 with a porcelain layer still seems very interesting in that aspect
to me.

>> 5. In case of replacing BusyBox with something that lacks an
>> editor, what would become the default? nvi, vim, neovim, elvis
>> traditional vi, nano or vis? Or maybe there will be two like
>> in OpenBSD or a load as in Slackware?
> 
> I'd just do a minimal (static?) vim build and forget about it.
> 
>> 6. What would be the default shell? mksh, pksh or dash? Or maybe
>> bash?
> 
> dash
> 
> I'd like to start sending some patches to realize this. I have a tracker
> for things I want to work on for Alpine:
> 
> https://todo.sr.ht/~sircmpwn/alpine
> 
> I'm going to start with non-controversial changes like adding doas,
> ubase, and shadow to aports while we discuess the harder points.

Any particular reason you prefer dash over ash? I’m curious. :-)

> 
> --
> Drew DeVault

- Shiz
Jakub Jirutka
Details
Message ID
<8D4CA20B-0098-420F-BA07-8978473FAFB4@jirutka.cz>
In-Reply-To
<5A25DE1D.6020602@adelielinux.org> (view parent)
Sender timestamp
1512441670
DKIM signature
missing
Download raw message
> The amount of things that are broken by not having `useradd` is
insane.

Maybe on Adélie, I've never encountered any issue on Alpine from not having useradd...

> Alpine build scripts
still think `adduser` and `addgroup` are the way to go.

Hm, we really should add a declarative way for creating users/groups in abuilds. Not (just) because of Adélie, the current approach has more problems.

> I could also write wrappers the other way around...

I was thinking about this several times, but always something more important appeared. I also don't like some behaviour of adduser.

> BTW, is there a reason Alpine doesn't ship shadow as a base dep?

Alpine's philosophy is small, simple and secure. shadow is not very small and it depends on PAM which is everything but small and simple. Moreover, it's mostly not really needed and useful. I surely don't wanna this in *base* system.

Jakub

(I'm sending this mail from mobile, so please forgive me typos etc.)

On 5 December 2017 00:45:33 CET, "A. Wilcox" <awilfox@adelielinux.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>On 04/12/17 17:00, Shiz wrote:
>>> On 4 Dec 2017, at 21:30, Drew DeVault <ddevault@vistarmedia.com>
>>> wrote: I would also recommend just porting shadow over using
>>> busybox user management tooling. I think `useradd` et al has a
>>> more Unix design than `adduser` et al. Thankfully the shadow
>>> codebase hasn't yet been corrupted beyond saving by the broader
>>> Linux ecosystem's influence.
>> 
>> Definitely agree with this. I am also of the opinion that `useradd`
>> and friends seem more commonly used, and it’s a shame to have to
>> recommend using the shadow package for everyone that wants to
>> either use it themselves or have tooling using it.
>
>
>The amount of things that are broken by not having `useradd` is
>insane.  We ship shadow in base in Adélie anyway, so this isn't too
>big of an issue, but what is an issue is that Alpine build scripts
>still think `adduser` and `addgroup` are the way to go.  Our builders
>don't have busybox so I had to write clumsy shell shims to 'translate'
>them.
>
>I can send them to the list if anyone would be interested; normally I
>would put a link, but our Git server ENOSPC'd and I'm still trying to
>clean up the pieces before bringing the web interface back online.
>
>I could also write wrappers the other way around if Alpine is really
>tied to using `adduser` and `addgroup` so that build scripts can use
>`useradd` and `groupadd` without a dependency on shadow.
>
>BTW, is there a reason Alpine doesn't ship shadow as a base dep?  Does
>Alpine really recommend use of tcb, or is it some other system?  I've
>never been able to figure this out and in fact this is why I gave up
>trying to deploy Alpine at my last employer.  We used LDAP and I
>couldn't for the life of me make Alpine login(1) use it.
>
>
>> s6 with a porcelain layer still seems very interesting
>
>
>+1.
>
>
>Best,
>- --arw
>
>
>- -- 
>A. Wilcox (awilfox)
>Project Lead, Adélie Linux
>http://adelielinux.org
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJaJd4ZAAoJEMspy1GSK50Uk9EP/2MJEp2JqObs8oTuI5Ehu6/6
>VN6e62vIVDgm6EM78/4dEOd7PgDygfcVaEa+LflczP6sgU5rZXpX5mDn5wxb2XaB
>iEsJ/esj306UkFIwnph8VU2z8+FdQ8SwcVD3IF++xKAbDHFCayYqt76nt44aNtjt
>9/2FaLha9apU/4Vbl8u5+9l57wvxkyLTNlt2IrPWiB6KOyp2Jl450clE1VYYfjlQ
>YroEab9klPToft4izScqPhlHc+AiqaiOwxNdKF2ekY3+bOVi73nZHejgibYtE0kj
>tJWnb7M1HlSaPOKQ3XIc+cA/QWGNYWkfg8AwtaWnwSz30LpbV8FOKoRf0AoU4FsU
>gTV8GQHKSLKbQgObZGVq9bpgsin8dWRcFbfij5P+sNZLg84nCfsCYH1TBjo+Y37d
>gLGFrfHBCHWH5qs039lHa9x6U5tlMcBndvkAwd0FSlQDZaNLHDG3x3Jyq0o7BbTD
>yGYj1CtW4udF7V9PxnV9r3PIvBu9OmPC/nNXf+3Mf/i4GOCGdS8IqE5FhFbmbtYG
>BOz+g+Z95V3ZWaE4K6B4nqOMLWjM+UyJNJkfKaUz0ppDFKWU+IFDbtwbnYwCCElW
>KRz/CY/MnOKi0CYEML7ouij4+SOMwjwv0qNAAS4/Xbqf1dt4JnAP/8gPUS3xSike
>GfD+idvKvp24NbAzjbmP
>=GK//
>-----END PGP SIGNATURE-----
>
>
>---
>Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
>Help:         alpine-devel+help@lists.alpinelinux.org
>---


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Shiz
Details
Message ID
<C9F4A117-23CC-434F-8BFF-A34EC0D1C426@shiz.me>
In-Reply-To
<8D4CA20B-0098-420F-BA07-8978473FAFB4@jirutka.cz> (view parent)
Sender timestamp
1512445494
DKIM signature
missing
Download raw message
> On 5 Dec 2017, at 03:41, Jakub Jirutka <jakub@jirutka.cz> wrote:
> 
>> The amount of things that are broken by not having `useradd` is
>> insane.
> 
> Maybe on Adélie, I've never encountered any issue on Alpine from not having useradd…

I see plenty of issues arising every day, just from questions on IRC and elsewhere.
> 
>> Alpine build scripts still think `adduser` and `addgroup` are the way to go.
> 
> Hm, we really should add a declarative way for creating users/groups in abuilds. Not
> (just) because of Adélie, the current approach has more problems.

+1 here.

- Shiz