[gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

https://bugs.gentoo.org/show_bug.cgi?id=508750
http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/
SHA256 139ac81c9478accd38a9eb667623d75997a2197cec36f184cd8d23e98a7e475b
(yet none of it is signed)

So libressl is meant as a drop-in replacement for openssl. Afais there
is no way around a virtual package, so I guess we can already add
virtual/openssl to the tree and start fixing dependencies.

The virtual would currently look like this:
=============================================
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=5

inherit multilib-build

DESCRIPTION="Virtual to select OpenSSL implementation"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
~arm-linux ~x86-linux"
IUSE=""

RDEPEND="dev-libs/openssl:0[${MULTILIB_USEDEP}]"
DEPEND=""
=============================================

I don't think it makes sense to add slot 0.9.8 as a virtual.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTwSwhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgnXMP/j7BU7PrL0QvBHUTFGUl4uuh
GswCkWv9BwrIuH4E73heVWWKxxZ8ILh/dShm2J2vY14Tuz+K+rOxIM3HXmQ7iozt
T3ihA55bK38BM/O0SlqRhQ9jpYE/1IaFDepffgdgRxgUfY/eVnTVWm3cNefGwTr+
tlnDO/1LksllBEoTPSHhGjj6lM7h3FzCpZ0F5u/5wluPEM0xm8bVYDZMsqHamIxH
hEUuOrVZG4gBk6bAaS6sKdT6yw1vcM+ZtNqI7fc4tjz8JmOI3vmAPJInbryKf48P
zp2xq/tGG8zo97JRAWqv89gs3sfemx7pEUqpMsT3YxL+fD6FgKbgNJT6BXy5iyIp
HI8NJQ/rns1Aer0PFMuIlKPj1Yzrux+QH0/N02Aw2uJ2QyjefXlE4pH3PHlmP7ql
84uAK4xboXU9fwgSeOXtVaTjaRQaOQc4ctNOa+cwFSFf/7jPfzp4hXdCH/n5BZrQ
vUny0TlUZfbSEPn50VKxkx7UdHzYmVLfd75MklKOe/h4iArtY/X6iu2rnEt3uCuY
ioDLhDA7NYCa8El9yDf5bO8scS4T8yWZEAi0kRG47Bayprk8JqIx0lIC97CbY3da
ui3yKTWckUbMm9cpdHVtkkDbLXzL1O1ps8SJOXyXJ+Ef8ZtRgbfNGUSFNiUmx7Zt
AZaPIGcNEUsqL9eiNexo
=Snnl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Anthony G. Basile]

On 07/12/14 08:37, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> https://bugs.gentoo.org/show_bug.cgi?id=508750
> http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/
> SHA256 139ac81c9478accd38a9eb667623d75997a2197cec36f184cd8d23e98a7e475b
> (yet none of it is signed)
>
> So libressl is meant as a drop-in replacement for openssl. Afais there
> is no way around a virtual package, so I guess we can already add
> virtual/openssl to the tree and start fixing dependencies.
>
> The virtual would currently look like this:
> =============================================
> # Copyright 1999-2014 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
>
> inherit multilib-build
>
> DESCRIPTION="Virtual to select OpenSSL implementation"
> HOMEPAGE=""
> SRC_URI=""
>
> LICENSE=""
> SLOT="0"
> KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
> ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
> ~arm-linux ~x86-linux"
> IUSE=""
>
> RDEPEND="dev-libs/openssl:0[${MULTILIB_USEDEP}]"
> DEPEND=""
> =============================================
>
> I don't think it makes sense to add slot 0.9.8 as a virtual.
> -----BEGIN PGP SIGNATURE-----
>
> iQJ8BAEBCgBmBQJTwSwhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
> MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgnXMP/j7BU7PrL0QvBHUTFGUl4uuh
> GswCkWv9BwrIuH4E73heVWWKxxZ8ILh/dShm2J2vY14Tuz+K+rOxIM3HXmQ7iozt
> T3ihA55bK38BM/O0SlqRhQ9jpYE/1IaFDepffgdgRxgUfY/eVnTVWm3cNefGwTr+
> tlnDO/1LksllBEoTPSHhGjj6lM7h3FzCpZ0F5u/5wluPEM0xm8bVYDZMsqHamIxH
> hEUuOrVZG4gBk6bAaS6sKdT6yw1vcM+ZtNqI7fc4tjz8JmOI3vmAPJInbryKf48P
> zp2xq/tGG8zo97JRAWqv89gs3sfemx7pEUqpMsT3YxL+fD6FgKbgNJT6BXy5iyIp
> HI8NJQ/rns1Aer0PFMuIlKPj1Yzrux+QH0/N02Aw2uJ2QyjefXlE4pH3PHlmP7ql
> 84uAK4xboXU9fwgSeOXtVaTjaRQaOQc4ctNOa+cwFSFf/7jPfzp4hXdCH/n5BZrQ
> vUny0TlUZfbSEPn50VKxkx7UdHzYmVLfd75MklKOe/h4iArtY/X6iu2rnEt3uCuY
> ioDLhDA7NYCa8El9yDf5bO8scS4T8yWZEAi0kRG47Bayprk8JqIx0lIC97CbY3da
> ui3yKTWckUbMm9cpdHVtkkDbLXzL1O1ps8SJOXyXJ+Ef8ZtRgbfNGUSFNiUmx7Zt
> AZaPIGcNEUsqL9eiNexo
> =Snnl
> -----END PGP SIGNATURE-----
>

I just did a quick count of all packages which refer to 
dev-libs/openssl.  I'm getting 590 packages.  This will be quite a task.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

Anthony G. Basile:
> 
> I just did a quick count of all packages which refer to
> dev-libs/openssl.  I'm getting 590 packages.  This will be quite a task.
> 

For ~arch we could probably do that with a script. For stable arch we
should ask maintainers to do it.

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Sat, Jul 12, 2014 at 12:37:53PM +0000, hasufell wrote:

*snip*

> KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
> ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
> ~arm-linux ~x86-linux"

If a provider of the virtual is already stable, you can commit the
virtual straight to stable.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Dirkjan Ochtman]

On Sat, Jul 12, 2014 at 2:37 PM, hasufell <hasufell@gentoo.org> wrote:
> So libressl is meant as a drop-in replacement for openssl.

Some caveats have already been discovered:

http://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/

Cheers,

Dirkjan

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

Dirkjan Ochtman:
> On Sat, Jul 12, 2014 at 2:37 PM, hasufell <hasufell@gentoo.org> wrote:
>> So libressl is meant as a drop-in replacement for openssl.
> 
> Some caveats have already been discovered:
> 
> http://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/
> 
> Cheers,
> 
> Dirkjan
> 

The Werror thing is fixed in the ebuild.

The next release is now signed and should enter the tree in the near
future, along with the virtual ebuilds.

So for people who want to help, I'd propose the following procedure:

1) Testing: https://github.com/gentoo/libressl (should already work with
'layman -a libressl')
It contains dummy openssl ebuilds so the virtuals are not yet needed. It
also contains a portable version of the signify tool (to verify the
libressl tarballs), patched wget and patched openssh with patch from Hanno.

I'd suggest to focus testing there, so we don't duplicate work.

2) depending on how big the fallout is we have to decide whether to add
libressl to ~arch or masked later and even have to decide whether adding
a virtual/openssl right now makes any sense. We'll shoot ourselves in
the foot if we add the virtual now and realize later that it doesn't
work out.

3) Depending on 2) add virtual/openssl and dev-libs/libressl to the tree
and start converting the tree (~arch ebuilds with simple openssl atoms
can probably be fixed with a script, see
https://bugs.gentoo.org/show_bug.cgi?id=508750#c23). Stable arch ebuilds
should probably be fixed by their respective maintainers. We should send
out a dev-announce too then.

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Matthew Summers]

On Sun, Jul 13, 2014 at 12:59 PM, hasufell <hasufell@gentoo.org> wrote:
> Dirkjan Ochtman:
>> On Sat, Jul 12, 2014 at 2:37 PM, hasufell <hasufell@gentoo.org> wrote:
>>> So libressl is meant as a drop-in replacement for openssl.
>>
>> Some caveats have already been discovered:
>>

So, libressl is really nowhere near ready for prime time or even late
night TV (perhaps the day time talk shows, but that is a stretch given
the PRNG situation). I think preparing a virtual and updating
dependent ebuilds for the explosion of replacements is grand, however
we should make it _very_ clear to everyone that issues exist that make
libressl unsafe for anything other than play time.

Thanks,

Matthew Summers
Gentoo Foundation Inc.
GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

Matthew Summers:
> On Sun, Jul 13, 2014 at 12:59 PM, hasufell <hasufell@gentoo.org> wrote:
>> Dirkjan Ochtman:
>>> On Sat, Jul 12, 2014 at 2:37 PM, hasufell <hasufell@gentoo.org> wrote:
>>>> So libressl is meant as a drop-in replacement for openssl.
>>>
>>> Some caveats have already been discovered:
>>>
> 
> So, libressl is really nowhere near ready for prime time or even late
> night TV (perhaps the day time talk shows, but that is a stretch given
> the PRNG situation). I think preparing a virtual and updating
> dependent ebuilds for the explosion of replacements is grand, however
> we should make it _very_ clear to everyone that issues exist that make
> libressl unsafe for anything other than play time.
> 


Yep, it's pretty rough currently. Also, it seems a lot of upstreams
(like python) rather want to wait until the libressl API gets somewhat
stable before starting to throw patches around.

But we can certainly start to introduce the virtual with
dev-libs/openssl as the only provider.

[gentoo-dev] Re: [RFC] LibreSSL, introduce virtual/openssl

[Duncan]

Matthew Summers posted on Tue, 15 Jul 2014 09:18:23 -0500 as excerpted:

> So, libressl is really nowhere near ready for prime time or even late
> night TV (perhaps the day time talk shows, but that is a stretch given
> the PRNG situation). I think preparing a virtual and updating dependent
> ebuilds for the explosion of replacements is grand, however we should
> make it _very_ clear to everyone that issues exist that make libressl
> unsafe for anything other than play time.

Here's another link for those following along:

Ars-technica (via LWN):

OpenSSL fork LibreSSL is declared "unsafe for Linux"

http://lwn.net/Articles/605509/rss

Basically it's a pid-duplication issue, aka an "I'm my own grandpa" 
issue, as someone mentions in the comments.

There's also a note both in the comments and now on the original Ars 
article saying a patch has already been pushed, but the point stands, 
"nowhere near ready for prime time" indeed.

It'll take a bit of time, but for now as already suggested, introducing 
the virtual with the single openssl provider does seem reasonable.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

Regarding the last libav discussion I think we should also go with a
"libressl" USE flag instead of creating a virtual that makes handling
SUBSLOTs impossible.

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Dnia 2015-01-23, o godz. 01:51:24
hasufell <hasufell@gentoo.org> napisał(a):

> Regarding the last libav discussion I think we should also go with a
> "libressl" USE flag instead of creating a virtual that makes handling
> SUBSLOTs impossible.

If libressl and openssl would have matching ABIs, that wouldn't be
necessary and you could what virtual/libudev does, i.e. explicit
subslot deps.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

But they don't. See my two blog posts on the matter. ABI compatibility is
explicitly not. What they care about.
On 23 Jan 2015 05:56, "Michał Górny" <mgorny@gentoo.org> wrote:

> Dnia 2015-01-23, o godz. 01:51:24
> hasufell <hasufell@gentoo.org> napisał(a):
>
> > Regarding the last libav discussion I think we should also go with a
> > "libressl" USE flag instead of creating a virtual that makes handling
> > SUBSLOTs impossible.
>
> If libressl and openssl would have matching ABIs, that wouldn't be
> necessary and you could what virtual/libudev does, i.e. explicit
> subslot deps.
>
> --
> Best regards,
> Michał Górny
>

[-- Attachment #2: Type: text/html, Size: 991 bytes --]

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Anthony G. Basile]

On 01/23/15 00:56, Michał Górny wrote:
> Dnia 2015-01-23, o godz. 01:51:24
> hasufell <hasufell@gentoo.org> napisał(a):
>
>> Regarding the last libav discussion I think we should also go with a
>> "libressl" USE flag instead of creating a virtual that makes handling
>> SUBSLOTs impossible.
> If libressl and openssl would have matching ABIs, that wouldn't be
> necessary and you could what virtual/libudev does, i.e. explicit
> subslot deps.
>
*if*  I'm not sure they will even though that's the plan.  If you look 
in the libressl overlay, you'll see lots of patches to make big ticket 
items like apache play nice with libressl.  These patches involve things 
like

+#ifndef HAVE_SSL_CTX_USE_CERTIFICATE_CHAIN
        int SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int, 
pem_password_cb *);
+#else
+    int _SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int, 
pem_password_cb *);
+#endif

which points to the differences in functions are being exported by the 
two.   This makes me lean towards a USE flag which can also be tied to 
applying patches rather than a virtual which is better suited for simple 
drop in substitutions.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

Anthony G. Basile:
> On 01/23/15 00:56, Michał Górny wrote:
>> Dnia 2015-01-23, o godz. 01:51:24
>> hasufell <hasufell@gentoo.org> napisał(a):
>>
>>> Regarding the last libav discussion I think we should also go with a
>>> "libressl" USE flag instead of creating a virtual that makes handling
>>> SUBSLOTs impossible.
>> If libressl and openssl would have matching ABIs, that wouldn't be
>> necessary and you could what virtual/libudev does, i.e. explicit
>> subslot deps.
>>
> *if*  I'm not sure they will even though that's the plan.  If you look
> in the libressl overlay, you'll see lots of patches to make big ticket
> items like apache play nice with libressl.  These patches involve things
> like
> 
> +#ifndef HAVE_SSL_CTX_USE_CERTIFICATE_CHAIN
>        int SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int,
> pem_password_cb *);
> +#else
> +    int _SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int,
> pem_password_cb *);
> +#endif
> 
> which points to the differences in functions are being exported by the
> two.   This makes me lean towards a USE flag which can also be tied to
> applying patches rather than a virtual which is better suited for simple
> drop in substitutions.
> 

The problem I see now is that people will have a hard time to actually
switch, because unlike gnutls we cannot have openssl and libressl be
installed at the same time.

For people to be able to switch we'd have to add libressl USE flags
everywhere, even if we don't know if it builds.

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Rich Freeman]

On Fri, Jan 23, 2015 at 3:18 PM, hasufell <hasufell@gentoo.org> wrote:
>
> The problem I see now is that people will have a hard time to actually
> switch, because unlike gnutls we cannot have openssl and libressl be
> installed at the same time.
>

I personally find it annoying when people fork projects, decide not to
maintain ABI compatibility with the original project, and then keep
filenames the same/etc such that the packages collide in their
recommended configurations.

I get that in the beginning everybody is just getting started and you
just don't have time to do anything other than revert some annoying
commits and maybe strip all the copyright notices (ducks!).  However,
projects should quickly decide whether they intend to remain
compatible or not (I get that there are valid reasons for either
depending on the circumstances), and if the latter change their
filenames/etc.

-- 
Rich

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Peter Stuge]

Rich Freeman wrote:
> I personally find it annoying when people fork projects, decide not to
> maintain ABI compatibility with the original project, and then keep
> filenames the same/etc such that the packages collide in their
> recommended configurations.

Some people do it on purpose, with the outspoken goal of doing
maximum harm to the original project and lock users into the fork.


> projects should quickly decide whether they intend to remain
> compatible or not (I get that there are valid reasons for either
> depending on the circumstances), and if the latter change their
> filenames/etc.

There are no unicorns on the internet. :\


//Peter

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Rich Freeman]

On Mon, Jan 26, 2015 at 5:43 AM, Peter Stuge <peter@stuge.se> wrote:
> Rich Freeman wrote:
>> I personally find it annoying when people fork projects, decide not to
>> maintain ABI compatibility with the original project, and then keep
>> filenames the same/etc such that the packages collide in their
>> recommended configurations.
>
> Some people do it on purpose, with the outspoken goal of doing
> maximum harm to the original project and lock users into the fork.
>

In such cases it probably would be helpful if distros talked to each
other and agreed to hack the build so that the new files would not
collide.  That then leaves the upstream package with two choices -
keep their build the same so that anybody who uses it to develop
against their library ends up with a build that doesn't work on any
actual distro, or play nice.

A NyxOS-like approach where you just prefix EVERYTHING on the system
might also work.  However, you'd still have issues unless you patched
anything that looked in a common area to not do that (like looking for
init.d scripts and systemd units - there wouldn't be an /etc/init.d,
but rather a bazillion /pkg/guid/etc/init.d directories or something
like that).  Also note, I'm not saying NyxOS does it this way - I
don't know exactly what they are doing.

-- 
Rich

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Peter Stuge]

Rich Freeman wrote:
> >> I personally find it annoying when people fork projects, decide not to
> >> maintain ABI compatibility with the original project, and then keep
> >> filenames the same/etc such that the packages collide in their
> >> recommended configurations.
> >
> > Some people do it on purpose, with the outspoken goal of doing
> > maximum harm to the original project and lock users into the fork.
> 
> In such cases it probably would be helpful if distros talked to each
> other and agreed to hack the build so that the new files would not
> collide.

Yes, I think that would be very helpful.

Unfortunately, my experience is that package maintainers in (all!)
distros either buy into convenient but wholly untrue propaganda or
simply settle for doing the same as "everyone else".


> That then leaves the upstream package with two choices - keep their
> build the same so that anybody who uses it to develop against their
> library ends up with a build that doesn't work on any actual distro,
> or play nice.

That is sadly a unicorn.


> A NyxOS-like approach where you just prefix EVERYTHING on the system
> might also work.

Yes, this is an interesting idea, and a good way to shield users from
evil.


> there wouldn't be an /etc/init.d, but rather a bazillion
> /pkg/guid/etc/init.d directories or something like that

I guess an abstraction akin to pkg-config could solve the problem.


//Peter

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[Rich Freeman]

On Jan 26, 2015 11:01 AM, "Peter Stuge" <peter@stuge.se> wrote:
>
> Rich Freeman wrote:
>
>
> > there wouldn't be an /etc/init.d, but rather a bazillion
> > /pkg/guid/etc/init.d directories or something like that
>
> I guess an abstraction akin to pkg-config could solve the problem.
>

Sort of. You can't call a service "mysql" if both mysql and mariadb
use that name.  Namespaces seem to always be a compromise between
convenience (I'm a sysadmin, not a system), and flexibility (if we
just identified users by guids and expected RSA authentication at the
keyboard we'd never have a problem).

-- 
Rich

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

[hasufell]

On 01/26/2015 01:08 PM, Rich Freeman wrote:
> On Mon, Jan 26, 2015 at 5:43 AM, Peter Stuge <peter@stuge.se> wrote:
>> Rich Freeman wrote:
>>> I personally find it annoying when people fork projects, decide not to
>>> maintain ABI compatibility with the original project, and then keep
>>> filenames the same/etc such that the packages collide in their
>>> recommended configurations.
>>
>> Some people do it on purpose, with the outspoken goal of doing
>> maximum harm to the original project and lock users into the fork.
>>
> 
> In such cases it probably would be helpful if distros talked to each
> other and agreed to hack the build so that the new files would not
> collide.

That's the worst of all. Let's not become debian, please.