maria-developers team mailing list archive
Mailing list archive
Otto Kekäläinen <otto@xxxxxxxxx> writes:
> 2013-10-01 Otto Kekäläinen <otto@xxxxxxxx>:
>> 2013/10/1 Ondřej Surý <ondrej@xxxxxxxx>:
>>> - it would be better to repack the tarball and kill the upstream debian/
>>> directory to not mess with our packaging
>> I hope to merge my work upstream and that is easier if my changes are
>> a made on top of current upstream. I think most of the changes should
>> be useful for upstream too. Maybe you can participate in the process
>> to create patches and test that they work for upstream OK?
> there much easier. Although I will be needing help from somebody to
> make autobuild.sh and standard Debian builders work nicely on the same
> code base.
Wouldn't it be better to discard the existing debian/ stuff in the upstream
sources, and work from the native Debian packaging as the base?
The existing stuff has _so_ much legacy and crap, and little of value. It has
origins in some ancient copy of native Debian packages, then OurDelta hacked
it for their build infrastructure (the autobuild.sh stuff), then MariaDB for
our build infrastructure. It has desperately needed a cleanup for so
long. Since this cleanup has now been done in native Debian packaging, which
also makes unnecessary some of the hacks to work with native Debian packages,
it seems better to just use Otto's work as the base going forwards.
And in any case, the old reason for having debian packaging in-tree no longer
applies. Now, we need to make sure before each release of MariaDB that it will
play nicely with the upstream Debian packaging, and for this it seems most
useful to pull in the packaging from the Debian packaging git repo?
Well, in the end it is up to you. I suppose in any case there will be a wish
to provide 3rd-party MariaDB .debs, eg. to provide backports to older distros
of new versions. It just seems more natural to focus primarily on having good
native packages and then accommodating the 3rd-party stuff, rather than the
other way around?