Subject: [alpine-aports] [PATCH 2/2] testing/drbd9-grsec: upgrade to 9.0.2

From: Roland Kammerer <[email-masked]>
Date: Thu, 21 Apr 2016 23:22:27 +0200

- New upstream release
- Changed download url
---
 testing/drbd9-grsec/APKBUILD | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/testing/drbd9-grsec/APKBUILD b/testing/drbd9-grsec/APKBUILD
index ecf7d4c..db52fec 100644
--- a/testing/drbd9-grsec/APKBUILD
+++ b/testing/drbd9-grsec/APKBUILD
@@ -8,13 +8,13 @@ _kpkg=linux-$_flavor
 _kver=4.4.8
 _kpkgrel=0
 
-_usver=9.0.1
+_usver=9.0.2
 # upstream now also has a -rel in the tar-balls
 # set it here for "source", but don't mangle it into pkgrel/_mypkgrel
 # if there is a new upstream rel (eg. 9.0.1-2), we just increase _mypkgrel
 _usrel=1
 
-_mypkgrel=0
+_mypkgrel=1
 
 _kernelver=$_kver-r$_kpkgrel
 _abi_release=${_kver}-${_kpkgrel}-${_flavor}
@@ -31,7 +31,7 @@ depends_dev=""
 makedepends="linux-grsec-dev"
 install=""
 subpackages=""
-source="http://oss.linbit.com/$_usname/${_usver%.*}/$_usname-$_usver-$_usrel.tar.gz"
+source="http://www.drbd.org/download/$_usname/${_usver%.*}/$_usname-$_usver-$_usrel.tar.gz"
 
 _builddir=$srcdir/$_usname-$_usver-$_usrel
 prepare() {
@@ -68,6 +68,6 @@ package() {
 	make DESTDIR="$pkgdir" install || return 1
 }
 
-md5sums="0d1d50e225ee0c8058af4fe1442d5242  drbd-9.0.1-1.tar.gz"
-sha256sums="f0862fffa5d73c433598fe1957bab61a2ae7ae1c4c7c0cecbef760e67a65fe20  drbd-9.0.1-1.tar.gz"
-sha512sums="0deb07d5c0217d35f85902064725311b3b74fe53ccb7faddb16624654c04edb44fb9462b0d967b1eb618a658ed66d32e71aa2b2048aa3fcd43a95d0f099f55d4  drbd-9.0.1-1.tar.gz"
+md5sums="b906e860f97fa4b0652f499a8b22c260  drbd-9.0.2-1.tar.gz"
+sha256sums="507de8869fa7f6b54a68554e6203a4ca3fc39adc85016fbfe9bc6b9b43d04c9f  drbd-9.0.2-1.tar.gz"
+sha512sums="45b14690e1b063be5e64244ac91e096542f1805f15936ad89ed59716f93a585927f228b920008bba736d4096714901aa65d431684b8f54244dc643d72eec624f  drbd-9.0.2-1.tar.gz"
-- 
2.6.6

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 22 Apr 2016 14:24:44 +0200

On Thu, 21 Apr 2016 23:22:27 +0200

>  1 file changed, 6 insertions(+), 6 deletions(-)

This and drbdmanage was applied. Thanks!

I am about to do a v3.4 release. I wonder if you think we can move
drbd9-grsec and drbdmanage to main repository? can we expect upstream
bug fixes for at least 6 months (if any) and upstram sec fixes for
about 2 years?

Are there any reason to not move it to repository 'main'?

-nc

---

---

From: Roland Kammerer <[email-masked]>
Date: Fri, 22 Apr 2016 15:07:32 +0200

> bug fixes for at least 6 months (if any) and upstram sec fixes for

Hi Natanael,

How is the policy for "main" and a given release? Maybe I missed it, but
at a first look I did not find a policy. Are version bumps allowed? If
so, what are the rules? Guess "no regressions" would be one ;-). Or is
it more like Debian stable where the version is pinned and only fixup
patches are allowed?

Regards, rck

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 25 Apr 2016 12:22:02 +0200

On Fri, 22 Apr 2016 15:07:32 +0200

> it more like Debian stable where the version is pinned and only fixup

The general rule is that if you use a stable repository (eg v3.3), then
you should be able to `apk upgrade -U` without need to worry that
anything breaks. that means, we cannot break ABI in a stable branch. We
can not introduce changes that requires user to change configuration to
make things work.

Generally speaking, only bugfixes should go there.

We prefer using upstream version bumps over backporting patches (Debian
style) because it is less work for us, but often we backport sec fixes
because upstream only provides version bumps that breaks things (break
abi or require user to reconfig things).

We also accept exceptions, where we backport new functionality if there
are good reasons to do so and if it does not break anything for
existing users.

So, for drbd, we would like minor version bumps for v3.4/main and sec
fix releases. Those should preferable not introduce new functionality,
but we may accept them if they don't introduce breakages.

I don't have the impression that drbd introduce big revolutions every
minor release so I don't think there will be any problem.

What I don't want is, that in 1.5 years in future, there show up a
critical sec issue in drbd9 and the *only* way to fix it is to upgrade to
drbd13 which require full reconfiguration and ABI incompatible libary
updates and recompile of half the world.

Bascially what I want is to be sure that we can minor sec fix release
bump or maybe even getting help in backporting sec fixes for 2 years if
needed.

Thanks!

-nc

---

---

From: Roland Kammerer <[email-masked]>
Date: Mon, 25 Apr 2016 12:51:46 +0200

> bump or maybe even getting help in backporting sec fixes for 2 years if

In that case I suggest the following:

Let's move drbd9 to main. Security fixes and don't break the upgrade
path is something our (Linbit's) customers expect anyways. It should
always be save to upgrade drbd (kernel side and user space).

Drbdmanage is a relatively young project and while basically the same
rules apply, I simply don't want to make these guarantees. We are close
to 1.0, but who knows, there might be a 2.0 in a few months which breaks
the dbus API, configuration files, and what not. This should not happen,
but I don't want to maintain old crap I then don't really care about
anymore... So for now I think we should keep it in testing.

While drbdmanage makes using drbd a lot more comfortable, drbd backing
devices can be manually created and configuration files can be scp'ed.
Not having drbdmanage in main is no show stopper for drbd itself.

Regards, rck

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 25 Apr 2016 13:11:20 +0200

On Mon, 25 Apr 2016 12:51:46 +0200

> Not having drbdmanage in main is no show stopper for drbd itself.

we could also move it to "community" repo. then we only need provide
fixes for it til next stable branch (6 months).

The thing is that we don't build testing repo for stable releases, so
it will not be available for v3.4 users we move it to either main or
community.

-nc

---

---

From: Roland Kammerer <[email-masked]>
Date: Mon, 25 Apr 2016 13:38:13 +0200

> fixes for it til next stable branch (6 months).

Sounds reasonable, ok from my side. 

Regards, rck

---