I think so.

Though may also want to alter "mgarepo import" so that it first check if the package had already been imported & obsolted (in that case, we probably want to keep the existing history and not diverge much from previous spec file)

(In reply to papoteur from comment #0)
> Is it only needed to have the command 
>  svn mv svn+ssh://svn.mageia.org/svn/packages/<release>/<package>
> svn+ssh://svn.mageia.org/svn/packages/obsolete/<package>
> ?

Basically yes. It should also support the "-l" argument of svn mv to define the commit log directly:

mgarepo obsolete <package> -l 'dropping <package> as it cannot cook fries properly'

About the <release>, I guess cauldron could be hardcoded (maybe in a clever way so that if we're forked and cauldron renamed to "potaufeu", it's easily adapted), I don't think we can or should obsolete packages in updates/<release number>.

OK, TV, I keep the idea for the import.
Barjac said that "obsoletes" command can be understood as doing the whole job of obsoleting, i.e. writing the Obsoletes commands in the related spec and so on. 

Thus, will a command "mv2obsol" or "mv2obsololete" be more accurate?

@Rémi
I will provide a -m option for the log message (as for ci).
And, yes, <release> will be cauldron as already hardcoded in layout.py.

I can also add an final output of the command suggested by pterjan:
 rpm -q --specfile SPECS/foo.spec --qf "Obsoletes: %{name} <= %{evr}\n"

This could help the packager to modify the spec of the new package or of task-obsoletes.

I think naming the command "mgarepo obsolete" (no "s") is fine enough, Barjac raises a good point but packagers should be familiar enough with the buildsystem to know what mgarepo does and doesn't. There are so far no mgarepo commands that I know that do edit spec files automatically, mgarepo only handles the SVN repo and binrepo in a convenient way.

And actually the act of obsoleting a package is most of the time not done in the package itself, but must be done in the other package that obsoletes it, so packagers would know expect mgarepo to find this new package by itself I hope :)

Having an output that gives a suggestion on how to obsolete is a good idea though.

For the output, it could be e.g.:

The package source was moved to the "obsolete" section of the SVN repo.
To actually obsolete existing binary packages, add those commands in the spec of the package that replaces the obsoleted package:
rpm -q --specfile SPECS/foo.spec --qf "Obsoletes: %{name} <= %{evr}\n"
rpm -q --specfile SPECS/foo.spec --qf "Provides: %{name}\n"

Hello,
I pushed a release to include the "obsolete" command.
It has the -m option to put a log message.
Papoteur

Fixed long time ago

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Fixed long time ago