search

Scout24 / yum-repo-server

Server to host and manage yum repositories via REST API
GNU General Public License v3.0
115 stars 19 forks source link

fuzzy filename matching for delete requests #21

Open ghost opened 11 years ago

ghost commented 11 years ago

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:

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

schlomo commented 11 years ago

+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:

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

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

mriehl commented 11 years ago

+1 but I am not sure I agree with

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 11 years ago

+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.

ghost commented 11 years ago

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 11 years ago

+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 11 years ago

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:

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 11 years ago

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.