Re: [Maria-developers] MariaDB
Otto Kekäläinen <otto@seravo.fi> writes:
2013-10-01 Otto Kekäläinen <otto@fsfe.org>:
2013/10/1 Ondřej Surý <ondrej@sury.org>:
- 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? - Kristian.
2014-01-31 Kristian Nielsen <knielsen@knielsen-hq.org>:
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
Yes, in upstream bzr repo debian/* has a lot of legacy and cruf, but still it has been updated to some extent by upstream MariaDB and there are even changes in debian/* between 5.5.32...35, so while packaging for Debian I still need to consider what upstream debian/* contains and do rather complex manual merge work that every time needs multiple build iterations to see that the build result stays the same for the two different debian/rules etc. Complexity is an enemy of quality so therefore I suggest that MariaDB upstream would update the upstream debian/* with the contents from https://github.com/ottok/mariadb-5.5. Even though the end result will be simpler and better quality, the move to it isn't trivial, as we need to consider the upgrade and install scenarios of current MariaDB.org repository users. It is not a problem, just work. i'll write about those in another e-mail. As a first step I suggest that MariaDB would create a new BuildBot instance 'kvm-deb-trusty-amd64' which builds for every commit it pulls from https://github.com/ottok/mariadb-5.5.git This would allow my packaging work benefit from the continuous integration framework MariaDB has in place and it would generate build logs anybody can use to verify that the new packaging performs everything correctly compared to other similar BuildBot runs. Also MariaDB.org does not have any Ubuntu 14.04 build tests yet, so this would at the same time provide those too. And while you are at it, please also consider setting up an instance 'kvm-deb-sid-pbuilder-amd64' that provides a Debian unstable environment and would run the builds using 'pbuilder', thus giving a view of how the package actually builds in Debian when submitted to Debian servers, with proper build dependency installations etc. This should take as input the MariaDB bzr commits. Initially these builds will fail, but once the merge of the two debian/* contents have been done, the build should start showing green. (I have the pbuilder commands ready and I can submit them to the person setting this up, I don't know who yet.) Does this sound like a good plan?
Otto Kekäläinen <otto@seravo.fi> writes:
2014-01-31 Kristian Nielsen <knielsen@knielsen-hq.org>:
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
Yes, in upstream bzr repo debian/* has a lot of legacy and cruf, but still it has been updated to some extent by upstream MariaDB and there are even changes in debian/* between 5.5.32...35, so while packaging for Debian I still need to consider what upstream debian/* contains and do rather complex manual merge work that every time needs multiple build iterations to see that the build result stays the same for the two different debian/rules etc.
Complexity is an enemy of quality so therefore I suggest that MariaDB upstream would update the upstream debian/* with the contents from https://github.com/ottok/mariadb-5.5.
Even though the end result will be simpler and better quality, the move to it isn't trivial, as we need to consider the upgrade and install scenarios of current MariaDB.org repository users. It is not a problem, just work. i'll write about those in another e-mail.
Yes, I agree. Both with this being a good solution, and with that it will need a lot of work. I suppose the most important thing is to get the Debian native packages updated with new features from 5.5.32...35, I suppose it's mostly new storage engines? If the work turns out bigger than available resources, and I had to choose, I would choose to break upgrades from the legacy 3rd-party packages. If we can get good native Debian packages, and new 3rd-party packages based closely on that, then I think it is worth it to break upgrades once (users will have to eg. apt-get remove the old stuff and apt-get install the new, once). Of course, if we can make everything work, then so much the better. My point is merely that I would put priority on getting everything right moving forward, and only solve the remaining single upgrade once the prio stuff is done.
As a first step I suggest that MariaDB would create a new BuildBot instance 'kvm-deb-trusty-amd64' which builds for every commit it pulls from https://github.com/ottok/mariadb-5.5.git
I can try to find time to setup this, but I will need an exact list of the commands that should be run. Basically, you need to provide a script that can be run in a clean VM and does what you want the buildbot to do. It doesn't have to be fancy, but it needs to be complete so that it is clear what needs to be done.
And while you are at it, please also consider setting up an instance 'kvm-deb-sid-pbuilder-amd64' that provides a Debian unstable
Daniel, can you prepare new sets of VMs for Ubuntu trusty and Debian sid? Then I can try to setup Buildbot to do these builds.
Does this sound like a good plan?
I think so. It is not clear to me who can do what, but the plan is good. - Kristian.
2014-02-04 Kristian Nielsen <knielsen@knielsen-hq.org>:
As a first step I suggest that MariaDB would create a new BuildBot instance 'kvm-deb-trusty-amd64' which builds for every commit it pulls from https://github.com/ottok/mariadb-5.5.git
I can try to find time to setup this, but I will need an exact list of the commands that should be run. Basically, you need to provide a script that can be run in a clean VM and does what you want the buildbot to do. It doesn't have to be fancy, but it needs to be complete so that it is clear what needs to be done.
Here is what I do on my home heater (very handy now during winter times): http://labs.seravo.fi/~otto/mariadb-repo/build.sh On your clean VM maybe this should be enough: gbp-clone --pristine-tar git://github.com/ottok/mariadb-5.5.git OR if you don't want to re-download all the time, then just doing a fetch and trigger a build if there are new commits with: git fetch origin if [ -n "$(git log HEAD..origin/master --oneline)" ]; then -> build The actual build part can be: gbp-pull --pristine-tar --force # takes in also the pristine-tar branch latest updates, force takes care of my potential git rebase action resolving git-buildpackage --git-pristine-tar # will eventually run dpkg-buildbackage just like debina/autobake.sh now does, no pbuilder is used with this plain command
And while you are at it, please also consider setting up an instance 'kvm-deb-sid-pbuilder-amd64' that provides a Debian unstable
Daniel, can you prepare new sets of VMs for Ubuntu trusty and Debian sid? Then I can try to setup Buildbot to do these builds.
With pbuilder the commands are same as above expect for: git-buildpackage --git-pristine-tar --git-notify=false --git-pbuilder --git-dist=sid --git-arch=amd64 Note that pbuilder will create a chroot, so it does not really need to be run inside a clean VM, it will semi-create one itself (but it does not hurt running it within a Debian unstable VM). In the VM that runs plain git-buildpackage the build depends need to be installed before, like you do with the other VMs now too.
Does this sound like a good plan?
I think so. It is not clear to me who can do what, but the plan is good.
OK!
On Tue, Feb 4, 2014 at 5:39 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
And while you are at it, please also consider setting up an instance 'kvm-deb-sid-pbuilder-amd64' that provides a Debian unstable
Daniel, can you prepare new sets of VMs for Ubuntu trusty and Debian sid? Then I can try to setup Buildbot to do these builds.
Ok, will do. I should have them up and running before the end of the week. Thanks. -- Daniel Bartholomew MariaDB
participants (3)
-
Daniel Bartholomew -
Kristian Nielsen -
Otto Kekäläinen