On Sun, Feb 11, 2018 at 2:00 PM, A. Wilcox <awilfox(a)adelielinux.org> wrote:
Currently we have a "fork" of aports.git. It's very
difficult to rebase
what we have, so it definitely needs to "restart" imo. We can move
aports.git to aports-historic.git and then re-clone from Alpine to make
it cleaner, but I think the better thing is to pull all the packages
that we want to keep different from Alpine and put them in system/ in
packages.git, leaving our aports.git fork strictly for changes we wish
Of course, since we can no longer merge in upstream changes, we would
therefore be tracking all the updates ourselves. This is why I would
like to be conservative.
These are the packages with changes that, for whatever reason, we cannot
merge upstream to Alpine. We should discuss what to do with them.
audacious (and audacious-plugins):
We are shipping the Qt variant. Alpine are shipping the Gtk variant.
Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream
this change. We could rename it audacious-qt and ship it in user/,
where even Alpine users could enjoy it, but it would need a maintainer.
I am more in favour of moving audacious to community, I just haven't
done it yet. But, Alpine ships a GTK+ desktop instead of a Qt one.
We have the -binsh virtual, the patch for bashrc location, and our own
bashrc file. None of these make sense for upstream. Unless I hear a
good argument for offering it in user/, I'm pretty sure this should be
We ship 2.29 instead of 2.28. We ship seven patches for everything from
tests to wrong behaviour with MIPS targets. ncopa did not seem
interested in bumping binutils until GCC is also bumped. This could be
moved to system/ since we are already maintaining it ourselves.
We have an /sbin/init virtual. I added busybox as a provider.
Honestly, this was primarily for Alpine's benefit. Since they don't
have a reason to ship a /sbin/init virtual I think this change can be
discarded; if anyone wants to use busybox as /sbin/init, please speak up
We may want to keep this for Adelie Core, as we will probably ship
busybox userland anyway in that case. But we may wind up just using
s6 as the init system there, so I don't know for sure.
They have a checkdepends of gawk which is satisfied by our mawk. Very
annoying as I don't want to ship gawk at all, but I suppose we can live
with it if it means we don't have to fork.
We could use a virtual here instead.
We have a bunch of hacks to support cross-compile, and a 32-bit PowerPC
patch. They don't release very often so I am fine with moving this to
I am okay with upstreaming this.
We are tracking 0.26 which is not yet released on their official site
because it includes fixes for big-endian that are irrelevant to Alpine.
I know the maintainers personally and I am fine with maintaining this
myself in system/.
Technically, s390x is big-endian but I doubt anyone is using exiv2 there.
We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype,
wavpack, libwebp, and pulseaudio output support. Almost none of those
are in Alpine main/ so it is impossible to add them to ffmpeg
dependencies upstream. I really don't want to maintain ffmpeg myself
since it is a frequent security flyer; if someone else wants to maintain
it in system/ then that is fine. As someone who *uses* three of those
plugins on my own system,
We should probably check this to make sure that we're not shipping
anything that violates patents.
Our freetype-profile.sh differs (we enable infinality by default). We
have no other changes. Alpine upstream temporarily did re-enable
infinality by default, but they did not like it (I believe there was
some bug in their XFCE 4 maybe?) so they reverted it.
Our gcc is wildly different from Alpine, so much so that this probably
belongs in system/ even if we do end up keeping an aports.git fork. In
addition, I don't feel comfortable with jumping to GCC 8 and Alpine has
been talking about it for retpoline support. This is going in system/
unless someone has a very good argument why it shouldn't.
It is complicated. I would prefer to have a gcc6 package for GCC 6
and a separate package for GCC 8. Shipping GCC 8 is necessary for
risc-v, which I am marginally interested in. Ideally, this is
something we would work with Alpine on.