Scout24/yum-repo-server

fuzzy filename matching for delete requests

Opened this issue · 7 comments

Deleted user commented

two ordinary users were wondering 10minutes why this, results into an http 500

repoclient  deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2.noarch

As yum-repo-server professional you recognize the missing extension 'rpm' while walking by ;)

So wouldn't it increase the user experience a lot to make it understand all of these requests:

  • repoclient deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2.noarch.rpm
  • repoclient deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2.noarch
  • repoclient deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2

This requires that #12 is solved before. Because we can easily confuse the semantic of delete-request between removing rpms and repositories.

schlomo commented

+1 I find this extremely annoying, especially if I want to clean up old junk. I am actually waiting with the big cleanup till this will be more user friendly.

I would also like to use these variants:

  • repoclient deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc should delete all versions
  • repoclient deleterpm is24-dev is24-tomcat-7-mysql-jdbc should delete all versions and src/noarch etc. This is the variant I miss most of all!

In general we should make it easy for users to delete matching source/binary RPMs. E.g.

  • repoclient deleterpm --all-binary is24-dev src/is24-tomcat-7-mysql-jdbc
  • repoclient deleterpm --all-binary is24-dev src/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2 (delete only this version)

This should also handle the case where a single source RPM creates several binary RPMs, e.g. for tomcat

mriehl commented

+1 but I am not sure I agree with

  • repoclient deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc should delete all versions

because the propagation logic currently states that a package without a version means "the latest version of the package".
I understand that with propagation the most common operation is propagating the most recent package, and with deletion it is deleting all the matching packages, but I think the discrepancy between "latest" and "everything" is just too much for the same syntax.

Maybe some kind of regex-based deletion?

I also totally agree with the need for a source/binary delete.
I also think most user issues due to the file name matching would go away if it was possible to delete RPMs from the web interface, since the usual workflow is opening the web view to copy the RPM name anyway.

heroldus commented

+1, but carefull with regex based deletion. In my opinion is24-tomcat-7-mysql-jdbc-ext-1.0-0.noarch.rpm shouldn't be removed by the command above.

Deleted user commented

We need to distinguish between abilities of yum-repo-server and client modification to repoclient.

So far this is about backend functionality of yum-repo-server.

Maybe we can split it up in backend (this) and frontend client modifications.

In my opinion, the client should learn search for rpm and handle the deletion via wildcards. The server should allow removal without the suffixes <noarch|src|etc>.rpm. So we maybe would have one cmdline call from shell with repoclient, but many calls from repoclient to yum-repo-server.

This is my current favourite. Let the client handle most things and keep the server straight-forward.

bvoss commented

+1 for the use case
But I don't thinkt that one Http DELETE should delete resources based on an regex and even not under another path (in case of the corresponding src rpms). I think this is not RESTful and there might be other clients than the repoclient which wouldn't expect this behavior.

So I would also suggest a split of functionality.
On the serverside we should provide a much clearer error message on Http DELETEs that dosen't match
and
a method for listing binary/src rpms matching a given name. May be something like

GET /repo/<reponame>/listrpms/<rpmname>
{ binary: ["noarch/rpmname-1.0.noarch.rpm", "noarch/rpmname-2.0.noarch.rpm"],
  source: ["src/rpmname-1.0.src.rpm"]}

for our tomcat example:

GET /repo/is24-dev/listrpms/is24-tomcat-7-mysql-jdbc
{ binary: ["noarch/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2.noarch.rpm", "noarch/is24-tomcat-7-mysql-jdbc-3.1.18-2.4146.1.noarch.rpm"],
  source: ["src/is24-tomcat-7-mysql-jdbc-5.1.18-2.24146.2.src.rpm"]

so the repoclient can show a list of files that will be deleted and send single/exact delete requests for each file.
We have the user experience we want and we stay RESTfull

schlomo commented

but I am not sure I agree with

  • repoclient deleterpm is24-dev noarch/is24-tomcat-7-mysql-jdbc should delete all versions

because the propagation logic currently states that a package without a version means "the latest version of the package".
I understand that with propagation the most common operation is propagating the most recent package, and with deletion it is deleting all the matching packages, but I think the discrepancy between "latest" and "everything" is just too much for the same syntax.

and

but carefull with regex based deletion. In my opinion is24-tomcat-7-mysql-jdbc-ext-1.0-0.noarch.rpm shouldn't be removed by the command above.

I think that the pattern matching should be semi-intelligent as follows:

  • NAME
  • NAME-VERSION
  • NAME-VERSION-RELEASE

So that mentioning a package name should match only packages with exactly this name, or name-version etc. Only if I add * then I would expect to have simple shell-style pattern matching (IMHO we don't need regex - keep it simple).

I agree with @bvoss that this might be better suited as a client feature with the server providing useful data...

mriehl commented

Any update or progress on this issue?

I'm willing to write the client code.
I can add the backend stuff too if nobody steps up but everyone agrees that the proposition from @bvoss sounds great.