Re: mysql/percona/maria...
On Sat, Oct 29, 2016 at 11:46:26 +0200, Jacek Konieczny wrote: > That (nameXY) would be more usefull for PostgreSQL, where old and new > version need to be installed for a database upgrade between different > major versions. Hm? Actually never did that for years... "pg_upgrade supports upgrades from 8.4.X and later to the current major release of PostgreSQL, including snapshot and alpha releases." What does require old version, and not just the previous one, but EVERY one in-between, is ownCloud: "Make sure that you dont skip a major release when upgrading via repositories. For example you cant upgrade from 8.1.x to 9.0.x directly as you would skip the 8.2.x major release" -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
utmp group to setup
todo: move utmp group to setup package, we already have "http" and "stats" users there it makes pam required base dependency, but i do not need pam in docker: bash-4.4# poldek -e pam mark pam-1.3.0-2.x86_64 Processing dependencies... pam-1.3.0-2.x86_64 marks pwdutils-3.2.19-4.x86_64 (req pam >= 0.99.7.1) pwdutils-3.2.19-4.x86_64 marks libutempter-1.1.6-5.x86_64 (req /usr/sbin/groupadd) libutempter-1.1.6-5.x86_64 marks rc-scripts-0.4.16-1.x86_64 (req libutempter >= 1.1.6-2) pwdutils-3.2.19-4.x86_64 marks SysVinit-2.88-18.x86_64 (req /usr/sbin/groupadd) pam-1.3.0-2.x86_64 marks util-linux-2.28-2.x86_64 (req pam >= 1:1.1.8-5) There are 6 packages to remove (5 marked by dependencies): R pam-1.3.0-2.x86_64 D SysVinit-2.88-18.x86_64 libutempter-1.1.6-5.x86_64 pwdutils-3.2.19-4.x86_64 rc-scripts-0.4.16-1.x86_64 util-linux-2.28-2.x86_64 This operation will free 14.8MB of disk space. Proceed? [N/y] n bash-4.4# -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mysql/percona/maria...
On 29.10.2016 12:17, Arkadiusz Miśkiewicz wrote: mysql 5.6 -> 5.7 MAY NOT be upgraded automatically. Here oracle 5.7 started fine with percona 5.6 db files but you are probably right and in some cases it won't work. percona used to apply some performance patches which changed precision of some variables. millisecs vs seconds, resuilting all queries being logged to slow.log causing disk to fill up quickly. that's just one incompatibility, some maybe even use performance_schema which maybe is different for those two vendors. so as long there's no automatic switch of upgrading same package replacing with different vendor binary i'm fine. altho i'd prefer to stay to percona version because we've been using it for so long. don't know what's the difference between maria/percona/oracle versions though. probably should search for some comparison table. -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mysql/percona/maria...
On 2016-10-29 11:17, Arkadiusz Miśkiewicz wrote: > On Saturday 29 of October 2016, Elan Ruusamäe wrote: >> On 29.10.2016 11:25, Elan Ruusamäe wrote: >>> should we introduce mysql57, mysql80 packages instead? > > Only if there are incompatible on upgrade path. To be verified with docs. > Otherwise all versions as mysql package. That (nameXY) would be more usefull for PostgreSQL, where old and new version need to be installed for a database upgrade between different major versions. Currently PostgreSQL upgrade in PLD is a problem. Though, I am not sure doing it right and maintaining later is worth the effort for our tiny team. >> here's some idea: >> >> 1. make percona-server.spec:5.7 clean upgrade path from mysql.spec:5.6 >> 2. do not build mysql.spec officially at all >> 3. build system tools using percona-server-devel via "Provides: >> mysql-devel" 4. mariadb - ship it only if it does not conflict with >> mysql-libs or mysql-devel > > Sounds good to me. > > (I would switch entire distribution to mariadb though (but keep percona > server > package, too) Sound goot to me to. It seems other distributions do similarily – mariadb is used instead of Oracle mysql and no non-Oracle mysql fork is packaged as 'mysql'. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mysql/percona/maria...
On Saturday 29 of October 2016, Elan Ruusamäe wrote: > On 29.10.2016 11:25, Elan Ruusamäe wrote: > > hi > > > > how is it planned to handle that mysql.spec is now different product > > (mysql vs percona) > > and all those mariadb and percona-server packages. > > > > mysql 5.6 -> 5.7 MAY NOT be upgraded automatically. Here oracle 5.7 started fine with percona 5.6 db files but you are probably right and in some cases it won't work. > > if someone used > > features from percona-server 5.6 that are now not present in > > mysql-community version in mysql.spec 5.7 their systems would be BROKEN. > > > > some idea: rename mysql.spec to mysql-community.spec ? > > > > should we introduce mysql57, mysql80 packages instead? Only if there are incompatible on upgrade path. To be verified with docs. Otherwise all versions as mysql package. > > > > ps: fedora has their mysql named as community-mysql.spec > > here's some idea: > > 1. make percona-server.spec:5.7 clean upgrade path from mysql.spec:5.6 > 2. do not build mysql.spec officially at all > 3. build system tools using percona-server-devel via "Provides: > mysql-devel" 4. mariadb - ship it only if it does not conflict with > mysql-libs or mysql-devel Sounds good to me. (I would switch entire distribution to mariadb though (but keep percona server package, too) -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mysql/percona/maria...
On 29.10.2016 11:25, Elan Ruusamäe wrote: hi how is it planned to handle that mysql.spec is now different product (mysql vs percona) and all those mariadb and percona-server packages. mysql 5.6 -> 5.7 MAY NOT be upgraded automatically. if someone used features from percona-server 5.6 that are now not present in mysql-community version in mysql.spec 5.7 their systems would be BROKEN. some idea: rename mysql.spec to mysql-community.spec ? should we introduce mysql57, mysql80 packages instead? ps: fedora has their mysql named as community-mysql.spec here's some idea: 1. make percona-server.spec:5.7 clean upgrade path from mysql.spec:5.6 2. do not build mysql.spec officially at all 3. build system tools using percona-server-devel via "Provides: mysql-devel" 4. mariadb - ship it only if it does not conflict with mysql-libs or mysql-devel -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
mysql/percona/maria...
hi how is it planned to handle that mysql.spec is now different product (mysql vs percona) and all those mariadb and percona-server packages. mysql 5.6 -> 5.7 MAY NOT be upgraded automatically. if someone used features from percona-server 5.6 that are now not present in mysql-community version in mysql.spec 5.7 their systems would be BROKEN. some idea: rename mysql.spec to mysql-community.spec ? should we introduce mysql57, mysql80 packages instead? ps: fedora has their mysql named as community-mysql.spec -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
