Hello,
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
> 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.
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.
> 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.
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.
> 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.
We could use a virtual here instead.
> 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/.
I am okay with upstreaming this.
> 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/.
Technically, s390x is big-endian but I doubt anyone is using exiv2 there.
> 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,
We should probably check this to make sure that we're not shipping
anything that violates patents.
> 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.
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.
William
Received on Mon Feb 12 2018 - 00:01:58 UTC