CentOS 7.8

Based on MDEV-3952 and faac8db6 mytop shouldn't be part of client component in rpm. In debian it is part of the client.
This should be a existing (Mytop) package probably serg?

No, I used "Mytop" only to avoid it being packaged into RPMs.
In Debian it was added only recently, committed by Otto in commit e0e5d8c5942, pushed by you.

RPMs quite intentionally don't have mytop script and should not have mytop.1 manpage, because there's a separate mytop rpm package in epel.

Why do we "build" the mytop script if we don't want to ship it?

I only include in Debian packaging the stuff our CMake scripts build and make available in the install directories.

If we don't want mytop, then I suggest it should be deleted from the sources completely and not used anywhere. The stuff that RPM and DEB includes should always be identical when possible.

The website or the original author does not seem to work: http://www.mysqlfanboy.com/mytop-3/

What is the relation to innotop?

Due to historical reasons we have packed along ` debian/additions/innotop`. Should we drop it as well and expect people get it directly from upstream (maintained by lefred at https://github.com/innotop/innotop)?

Unless we need a MariaDB-specific innotop and lefred refuses to accept patches, I would suggest not to package our own innotop.

we used to include mytop only in bintars, rpm and deb based distros had packages with mytop, we didn't need to provide our own outdated fork.

PR to remove mytop created in https://github.com/MariaDB/server/pull/1565

I could make a similar one about Innotop, should I?

Current version of mytop is MariaDB fork, there were already some contributions.
It already uses all patches from debian/ubuntu and is enhanced version with MariaDBD perl connector and resizing features, please see PR #215 and PR #1327 as well as MDEV-4476 (in comments you will find evolution of PR #215 and time it took for contributor to do contribution).
otto I would like to leave a script as it can be run from source at least (we can drop mytop from client package) and also because of contributions in the past, so to merge PR #1565 without the script itself.
We are getting new PR's referencing client package of mytop PR #1566- 1567
serg what is your opinion about this?

This is a similar situation like TokuDB. In my opinion we should
either support and care about it, or remove it.

I think it is very problematic to have code in our sources that is at
the same time developed but not really developed. We end up spending a
lot of time reviewing and testing code ad-hoc that is outside of
normal QA processes. Quality of half-maintained code tend to
deteriorate, and the more it deteriorates, the more unproductive time
is spent on duck-taping it.

Also, if we really want to for mytop, it should use a different name
to avoid even more waste of time due to confusions. Maybe start a new
project at github.com/mariadb/mariadb-top?

I agree with you, just for the sake of contributions I would like to have it still, but if there was already similar case, I don't have any problem to use your full patch PR #1565.
I like your idea, maybe to create a new MDEV for that and see the votes in some period?

Okay. I stand corrected. Looking at https://repology.org/project/mytop/versions one can see that there are three versions of mytop in use:

• 1.6 old Jeremy Zawodny version, February 2007: https://github.com/jzawodn/mytop/tree/56c43a96
• 1.7 new Jeremy Zawodny version, March 2009: https://github.com/jzawodn/mytop/tree/4c9aced3e
• 1.9.1 Mark Grennan fork of 1.6, February, 2012

so by any measure it doesn't look like an actively (or at all) maintained project.
Let's keep and maintain it, then.

• client package should provide/obsolete mytop < 1.9.9
• we should merge all changes from 1.7

both RPM and DEB packages should include it.

serg Just to be explicit: you want mytop to be shipped as a separate package or continue to ship is as part of the mariadb-client-10.5 package?

Currently in .deb is is part of mariadb-client-10.5, but I opened https://github.com/MariaDB/server/pull/1571 which separates into a package of its own. Innotop continues to be shipped in the mariadb-client-10.5 package, but I can easily split that out as well, or completely remove it.

Please note that there are tens of patches in https://sources.debian.org/src/mytop/1.9.1-4/debian/ that further improve the 1.9.1 version. Maybe Anel should take those patches and apply them on our mytop fork? There is also a example config.

otto current version of mytop covers patches from debian (PR #215 and MDEV-4476 -comments are covering that).
So if the mytop should be part of client package (mariadb-client-10.5) than there is no need for your last PR (#1571) and also you can close PR #1565, since we will not remove it.
However PR#1566 should be tested since it is using my_print_defaults for a client package.

otto, I think it'd be a larger change and, perhaps, not justified yet. For now I'd keep it in the client package, just set the client package metadata that it replaces and conflicts with mytop package.

If users will be asking for a separate mytop package, so that they could use it without installing full mariadb-client, we could consider doing it. But for now I'd suggest the minimal change — update our mytop to include all all 1.7 and distro patches, package it, set package metadata correctly.

The mariadb-client-10.5 package already has in debian/control the proper Conflicts/Replaces lines, so there is no need to make any changes in Debian packaging.

To be sure, I also tested this on a Debian Sid system with mytop installed and then upgrading to MariaDB, it correctly removes the separate mytop package and replaces it with mytop from MariaDB:

The following additional packages will be installed:

  bzip2 cracklib-runtime file galera-4 gawk krb5-locales libaio1 libbz2-1.0 libc-dev-bin libc6 libc6-dev libcgi-fast-perl libcgi-pm-perl libclone-perl libcrack2 libcrypt-dev libedit2 libencode-locale-perl

  libexpat1 libfcgi-perl libgflags2.2 libgpm2 libgssapi-krb5-2 libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libicu67 libio-html-perl libjudydebian1

  libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libltdl7 liblwp-mediatypes-perl libmagic-mgc libmagic1 libmpdec2 libmpfr6 libncurses6 libodbc1 libpcre2-posix2 libpopt0 libprocps8 libpython3-stdlib

  libpython3.8-minimal libpython3.8-stdlib libreadline8 libsigsegv2 libsnappy1v5 libsqlite3-0 libssl1.1 libtimedate-perl liburi-perl libwrap0 libxml2 linux-libc-dev lsof manpages manpages-dev mime-support

  odbcinst odbcinst1debian2 procps psmisc python3 python3-minimal python3-mysqldb python3.8 python3.8-minimal readline-common rocksdb-tools rsync socat unixodbc wamerican xz-utils zlib1g-dev

Suggested packages:

  bzip2-doc gawk-doc glibc-doc libc-l10n locales gpm krb5-doc krb5-user libdata-dump-perl libipc-sharedcache-perl libmyodbc odbc-postgresql tdsodbc unixodbc-bin libwww-perl man-browser mailx netcat-openbsd

  tinyca patch python3-doc python3-tk python3-venv python3-mysqldb-dbg python3.8-venv python3.8-doc binutils binfmt-support readline-doc openssh-client openssh-server

The following packages will be REMOVED:

  mytop

The following NEW packages will be installed:

  bzip2 cracklib-runtime file galera-4 gawk krb5-locales libaio1 libc-dev-bin libc6-dev libcgi-fast-perl libcgi-pm-perl libclone-perl libcrack2 libcrypt-dev libedit2 libencode-locale-perl libexpat1

  libfcgi-perl libgflags2.2 libgpm2 libgssapi-krb5-2 libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libicu67 libio-html-perl libjudydebian1 libk5crypto3

  libkeyutils1 libkrb5-3 libkrb5support0 libltdl7 liblwp-mediatypes-perl libmagic-mgc libmagic1 libmariadb-dev libmariadb-dev-compat libmariadb3-compat libmariadbclient18 libmariadbd-dev libmariadbd19

  libmpdec2 libmpfr6 libmysqlclient18 libncurses6 libodbc1 libpcre2-posix2 libpopt0 libprocps8 libpython3-stdlib libpython3.8-minimal libpython3.8-stdlib libreadline8 libsigsegv2 libsnappy1v5 libsqlite3-0

  libssl1.1 libtimedate-perl liburi-perl libwrap0 libxml2 linux-libc-dev lsof manpages manpages-dev mariadb-backup mariadb-client mariadb-client-10.5 mariadb-client-core-10.5 mariadb-plugin-connect

  mariadb-plugin-cracklib-password-check mariadb-plugin-gssapi-client mariadb-plugin-gssapi-server mariadb-plugin-mroonga mariadb-plugin-oqgraph mariadb-plugin-rocksdb mariadb-plugin-spider mariadb-server

  mariadb-server-10.5 mariadb-server-core-10.5 mariadb-test mariadb-test-data mime-support odbcinst odbcinst1debian2 procps psmisc python3 python3-minimal python3-mysqldb python3.8 python3.8-minimal

  readline-common rocksdb-tools rsync socat unixodbc wamerican xz-utils zlib1g-dev

The following packages will be upgraded:

  libbz2-1.0 libc6 libmariadb3 mariadb-common mysql-common

5 upgraded, 102 newly installed, 1 to remove and 28 not upgraded.

Need to get 40.7 MB/115 MB of archives.

After this operation, 820 MB of additional disk space will be used.

Do you want to continue? [Y/n] 

So need to do any changes in debian/* for now.

Patches for mytop are in bb-10.5-anel-MDEV-22552 .

PR for moving my_print_defaults from mariadb-server-core-10.5 to mariadb-client-core-10.5 in deb packages at https://github.com/MariaDB/server/pull/1581

1581 covered also with bb-10.5-anel-MDEV-22552 for review.

• https://github.com/MariaDB/server/commit/3c81ed2f56 is ok
• https://github.com/MariaDB/server/commit/914fe72a3a is ok
• https://github.com/MariaDB/server/commit/8063b78fb7 see comments there
• https://github.com/MariaDB/server/commit/4a7d7bd0a is ok

also you didn't specify that our mytop obsoletes the other mytop. And you didn't merge all changes from other mytops, so it's not a superset yet.

Sorry, i just saw this MDEV now ; i am the one that did the changes on the MariaDB mytop.

Forking it to a new project and pushing for Debian and Redhat (and others that are providing a mytop package) official packaging to use it as as a replacement of the original that is not maintained anymore is a solution (but i am too lazy to do it myself) ; this way it could be removed of the MariaDB codebase and packaging would not have to be your "problem" anymore.

That would be ideal. But somebody has to maintain it. As long as nobody volunteers, we might have to do it.

Hi serg bb-10.5-anel-MDEV-22552 is updated per comments.
Here are two diffs to mytop1.9.1-4 and mytop1.7 (attachment in jira comment doesn't work).

Related Debian bug about the wish for somebody to maintain (again) mytop as a separate project/package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863968

anel, don't understand still:

• does this your mytop supports all features of mytops 1.9 and 1.7?
• does it obsolete all other mytops? should it?

Hi serg,

• from what I have seen diff to mytop_1-9 current version is:
  1. applying all changes (maybe implementation be different - for example different regex (example 1), MariaDB instead of Mysql example 2, different logic example 3, dbd mariadb module example, etc.., but functionality is the same) ,
  additionally
  2. enhancing with additional feature
  (like dynamical width change example, usage of process list stage example),
• from my point of view, current implementation is MariaDB specific, but it doesn't obsolete other mytops, at least 1.9. from debian-upstream (I don't see why other should be obsolete to use). As stated above some modifications are done as a part of MDEV-4476.

Let otto decide on that, but I think that if you don't obsolete/replace mytop from debian-upstream, a user won't be able to install mariadb-client if he has mytop installed. He'll have to uninstall mytop manually and then install mariadb-client. And it's more user-friendly to do it automatically, isn't it? There is no choice here, the user cannot have both.

I did base it on the latest mytop at the time (1.9) and there only has been some distro patches since that i applied if it was still needed (some fixed things that i did already fix on my side) and some others so it should obsolete other mytops which have not had upstream updates for years.

Hi serg, new patch(will change indentation) based on mail review.

anel, that wasn't really a review, just a few comments based on the patch.
Anyway, see above, perhaps mytop should obsolete other mytops after all?

The Mytop upstream is dead and the Debian package has not been updated
since January 2017: https://tracker.debian.org/pkg/mytop

Mytop needs a new upstream. Will MariaDB be the new upstream, that is
the question I guess? If yes, then invest in the script. If not, then
drop it. Or would Innotop suffice and make Mytop obsolete?

otto, I suspect that as long as nobody steps up we'll keep maintaining it.

anel, if I understand correctly, both otto and jb-boin say that this new mytop should obsolete old ones.

Updated last patch (with socket prefix + revert change for RPM) ff75d7bbf2e for the branch bb-10.5-anel-MDEV-22552, it has 5 commits now.
Ok based on the context of comment above, I agree old versions are obsolete.

so, will you commit a change that makes old versions obsolete?

I would like to, but don't have experience. I suppose it has to be done in /debian/control? Or there is some other way?

I asked faust to look a bit about suggested patch and test.

What are you about to change in debian/control?

We already discussed debian/* in https://jira.mariadb.org/browse/MDEV-22552?focusedCommentId=155143&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-155143 and https://jira.mariadb.org/browse/MDEV-22552?focusedCommentId=155509&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-155509 and I did not see any problems with current mytop packaging.

± grep mytop debian/*

debian/control:           mytop,

debian/control:          mytop,

debian/mariadb-client-10.5.install:usr/bin/mytop

debian/mariadb-client-10.5.install:usr/share/man/man1/mytop.1

If you do end up changing debian/*, please file a PR and assign me as reviewer.

otto s
I was thinking like this:

diff --git a/debian/control b/debian/control

index 94c4b22cdc3..d9cacf00799 100644

--- a/debian/control

+++ b/debian/control

@@ -376,7 +376,7 @@ Conflicts: mariadb-client (<< ${source:Version}),

            mysql-client-core-5.6 (<< ${source:Version}),

            mysql-client-core-5.7 (<< ${source:Version}),

            mysql-client-core-8.0 (<< ${source:Version}),

- mytop,

+ mytop (<< ${source:Version`}),

            virtual-mysql-client

 Breaks: mariadb-client-core-10.0,

         mariadb-client-core-10.1,

@@ -415,7 +415,7 @@ Replaces: mariadb-client (<< ${source:Version}),

           mysql-client-core-5.6 (<< ${source:Version}),

           mysql-client-core-5.7 (<< ${source:Version}),

           mysql-client-core-8.0 (<< ${source:Version}),

- mytop,

+ mytop (<< ${source:Version`}),

           virtual-mysql-client

 Provides: default-mysql-client,

           virtual-mysql-client

but per your comment seems like there is no need to do like above.
So I guess Serg was thinking about RPM in few comments above. Can you please do a patch/test for that?
Also can you please rebase https://github.com/mariadb/server/tree/bb-10.5-anel-MDEV-22552 (your commit) to latest 10.5 (PR #1581)?

julien.fritsch Status says "in review" but there are only two (closed) Pull Requests. I wonder what part is in review.

The PR to split out mytop was already done in https://github.com/MariaDB/server/pull/1571 but closed as there was a decision by Serg previously to not do this change. So in case you intend to do that after all, you don't need to do double work but just update and merge the existing PR. And make sure it lands in 10.6. This change (if made) should really not go into a stable release.

What is the status on this? I don't see any progress in 2021 so far, not responses to my previous comment.

I've looked at git diff 10.5...bb-10.5-anel-MDEV-22552 again (bb-10.5-anel-MDEV-22552 is ff75d7bbf2e).

• DEB packaging, debian/control
  • I don't think that mariadb-client should replace mariadb-server-core or mysql-server-core. Breaks and Conflicts are fine.
  • I don't know if it's allowed to add a new dependency in 10.5, namely, that mariadb-server-core now depends on mariadb-client-core.
• RPM packaging, cmake/cpack_rpm.cmake
  • MariaDB-server now must depend on the MariaDB-client >= 10.5.X (the version when you'll push this change), because with the new MariaDB-server and old MariaDB-client there won't be my_print_defaults anywhere at all.
  • Similarly, MariaDB-client must conflict with the MariaDB-server < 10.5.X

I took a quick look at https://github.com/MariaDB/server/compare/10.5...bb-10.5-anel-MDEV-22552.

Comments:

1) DO NOT DO THIS ON BRANCH 10.5. That is a stable release, you can't introduce new stuff there, let alone a whole new package. Put your work in 10.6.

2) The changes in debian/ don't include the actual mytop package. Just as a reminder I already did it in https://github.com/MariaDB/server/pull/1571/files, you just need to copy that code and make a new PR on 10.6...

3) I see my_print_defaults is moved from server package to client package. Why are you wasting time on that? It has already been done in https://github.com/MariaDB/server/pull/1581

4) As danblack already pointed out, mytop exists in Fedora already as a separate package: https://src.fedoraproject.org/rpms/mytop/blob/rawhide/f/mytop.spec (and in Debian too https://tracker.debian.org/pkg/mytop) so when you do the CPack for mytop now, you should make sure it is aligned with existing rpm package.

5)

#!/usr/bin/env perl

#!/usr/bin/perl -w

The opposite change was done in https://github.com/MariaDB/server/commit/37c88445e30d52c965bcb19b19fa710c3eb4fad9 so this seems inconsistent.

6) You have now 5 very small commits on your branch that each actually are the same change, so it would probably be best to squash those changes to one.

1) there's no new package there, mytop is moved from server to client, that's all
3) he's not, it's your own commit, https://github.com/MariaDB/server/commit/87f91f4314d, that is part of the diff

Mytop is already in the client package:

10.6$ grep mytop debian/*.install

debian/mariadb-client-10.6.install:usr/bin/mytop

debian/mariadb-client-10.6.install:usr/share/man/man1/mytop.1

otto serg thank you for your review.
From 5 commits in my working branch I removed 3 in new MDEV-25878 (what is not related to the description - mytop in RPM).
Commits that are left currently in working branch are:
1. https://github.com/MariaDB/server/commit/ca1d0edac9f61202b8249583cffb39ba30eb73a0
^ moving my_print_defaults to client component - RPM change
2. https://github.com/MariaDB/server/commit/87f91f4314d6c8b591a29fd8c89db6fedb6e1953
^ otto patch from PR #1581 that is obsolete/(part of the patch is pushed) to 10.5.2+ now.

The state of mytop regarding debian in MariaDB server:

• 10.5.2+:
  mytop moved to mariadb-client-10.5 package: http://github.com/MariaDB/server/commit/e0e5d8c5942a1eb0b0ae05b6296286193073e571
• 10.5.3+:
  mariadb-client-10.5 conflicts with mytop: https://github.com/MariaDB/server/commit/9ed7e967b3fe
• 10.6.0+
  moved my_print_defaults from server-core -> client-core in 10.6 since mytop requires it: https://github.com/MariaDB/server/commit/fc65417e7bcae88f15e1bfcd0ccebf1b06e02fd5

So mytop is already in mariadb-client package from 10.5+ and my_print_defaults in client-core package from 10.6+.
otto I don't plan to touch debian/ here regarding mytop on 10.5.
If there is something to do (don't see what could be ? - adding perl5-DBD-mysql/MariaDB dependency?) beside above analysis please create new MDEV for mytop and debian for 10.6 and please explain me what needs to be done.

serg commented your patch (PR #1581) for relations between mariadb-client-core and mariadb-server package that I had in my branch.
This change is visible in 10.6. now.
serg based on debian-policy there is suggestion if there is breaks rule it should go in conjuction with replaces.
Replaces rule https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces doc says:

It is usually an error for a package to contain files which are on the system in another package. 

However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new. 

The file will no longer be listed as “owned” by the old package and will be taken over by the new package. 

Normally, Breaks should be used in conjunction with Replaces.

I think we should add Conflicts in addition which is a stronger constraint compared to breaks -> otto?!

I will push soon patch for RPM only I guess 10.5 is ok to be target branch in this case.

I think we should add Conflicts in addition which is a stronger constraint compared to breaks -> Otto Kekäläinen?!

I did a thorough testing and cleanup of breaks/replaces/conflicts in
https://github.com/MariaDB/server/commit/62f5a4f06529008b06858c40a8cad419bf4921a3
For MariaDB 10.6 no further changes are needed and for 10.5 and older I would not touch them at this point. It is good to follow the Debian policy but most importantly we need to test and verify that in our specific case the upgrades actually proceed correctly in every conceivable scenario, and that I've done for 10.6.

Hi serg can you please review 2 commits bb-10.5-anel-MDEV-22552.
Testing result, analysis and some question for you additionally (not related to patch) can be found in Zulip CentOS thread.

looks good

Pushed to 10.5 with commits 2011fcf87ddb0dc and 395a033237686f2