3 p.m.
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
to upstream.
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.
bash:
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
in system/.
binutils:
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.
busybox:
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
now.
check:
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.
coreutils:
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
system/.
exiv2:
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/.
ffmpeg:
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,
freetype:
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.
gcc:
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.
I'm limiting each email to 10 packages. See you in the next message!
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org