Unable to change origin url with `ostree admin set-origin` if remote already exists

[RomanValov]

With the ostree admin set-origin command I'm able to create a new origin/remote with url specified. However if I specify origin/remote that is already exists, it's url is not updated and no error is shown:

[root@ostree ~]# ostree admin status
* fedora-iot 58bcb3f5742dfe1390c71cf5903fe596bc51a54073e8e5642a2e55b88cbf029f.0
    Version: 34.20210624.0
    origin refspec: fedora-iot:fedora/stable/x86_64/iot
    GPG: Signature made Thu Jun 24 11:24:28 2021 using RSA key ID 1161AE6945719A39
    GPG: Good signature from "Fedora <[email protected]>"
[root@ostree ~]# ostree remote list -u
fedora-iot  https://dl.fedoraproject.org/iot/repo/
[root@ostree ~]# ostree admin set-origin fedora-iot https://example.org/test/
[root@ostree ~]# echo $?
0
[root@ostree ~]# ostree admin set-origin fedora-tmp https://example.org/test/
[root@ostree ~]# echo $?
0
[root@ostree ~]# ostree remote list -u
fedora-iot  https://dl.fedoraproject.org/iot/repo/
fedora-tmp  https://example.org/test/

[bauen1]

I think the logic of ostree admin set-origin needs some other improvements, or generalizations.

Or maybe only the man page needs to be updated.

I've deployed a specific commit, and now I'm in this:

sysadmin@companion-cube:~$ sudo ostree admin status                                          
* default 997545685a33945d95e3aa5fef34909462ff7402a5435f46c3e531c2173267dd.1 
    origin refspec: origin:997545685a33945d95e3aa5fef34909462ff7402a5435f46c3e531c2173267dd
    GPG: Signature made Wed 22 Jan 2025 04:16:53 PM CET using RSA key ID DEDEB099A4F90106  
    GPG: Good signature from "bauen1 OSTree Automatic Signing Key <[email protected]>"    
    GPG: Key expires Tue 17 Aug 2027 10:09:46 PM CEST                                
  default 997545685a33945d95e3aa5fef34909462ff7402a5435f46c3e531c2173267dd.0 (rollback)
    Pinned: yes                                                                              
    origin refspec: local:companion-cube/testing
  default 5b247301b8455925cb9e9fab4bd7dc192133ad375913399d6fadd990a83811c7.0
    origin refspec: local:companion-cube/testing                            
  default 7528cf4a0ea483e3d22ea77ab857962ad3069899d5f4db1f4e02ca0c355a943e.0
    Pinned: yes                                                                              
    origin refspec: local:companion-cube/testing

I would like to set the origin of the current deployment back to tracking local:companion-cube/testing, but ostree admin set-origin won't work for this due to the above - and even if it did, it seems unnecessary to specify all of the remote configurations again. After all, I'm only trying to set the origin, not also add a remote.

I'm very much leaning towards ostree admin set-origin should only replace the .origin file of an arbitrary deployment, and assume that the remote specified already exists, perhaps even that only if it's required for internal consistency of the OSTree repository / deployments.

Okay, actually testing this out and simply running

sudo ostree admin set-origin local "" companion-cube/testing

sysadmin@companion-cube:~$ sudo ostree admin status
* default 997545685a33945d95e3aa5fef34909462ff7402a5435f46c3e531c2173267dd.1
    origin refspec: local:companion-cube/testing
  default 997545685a33945d95e3aa5fef34909462ff7402a5435f46c3e531c2173267dd.0 (rollback)
    Pinned: yes
    origin refspec: local:companion-cube/testing
  default 5b247301b8455925cb9e9fab4bd7dc192133ad375913399d6fadd990a83811c7.0
    origin refspec: local:companion-cube/testing
  default 7528cf4a0ea483e3d22ea77ab857962ad3069899d5f4db1f4e02ca0c355a943e.0
    Pinned: yes
    origin refspec: local:companion-cube/testing

Does lead to the (un)expected results ....

The manpage says Add a new remote named REMOTENAME (if it does not already exist)., so I'd say this isn't a bug, but rather just very confusing behavior / documentation.

I think something like this would be more useful:

ostree admin set-origin  {REMOTENAME} {URL} [BRANCH]
# ^ accepted for backwards compatibility reasons I suppose, or perhaps deprecate it with a warning about confusing behavior ?

# Below variants are what I would propose, that do not create the remote (or modify the URL)
ostree admin set-origin {REMOTENAME}:{REFSPEC}
# ^ set the refspec of the selected deployment as given to `{REMOTENAME}:{REFSPEC}`
ostree admin set-origin --set-remote {REMOTENAME}
# ^ update only the remote name part of the refspec
ostree admin set-origin --set-ref {REF}
# ^ update only the ref of the refspec
ostree admin set-origin --set-remote {REMOTENAME} --set-ref {REF}
# ^ update both / equivalent to {REMOTENAME}:{REFSPEC} ?