After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695625 - ftpadmin install --force $tarball fails to do what it says on the tin
ftpadmin install --force $tarball fails to do what it says on the tin
Status: RESOLVED OBSOLETE
Product: sysadmin
Classification: Infrastructure
Component: Mirrors
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
Depends on:
Blocks:
 
 
Reported: 2013-03-11 12:59 UTC by Martyn Russell
Modified: 2013-11-21 14:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martyn Russell 2013-03-11 12:59:29 UTC
I installed a tracker 0.15.3 tarball but the compiled sources (.c files from Vala included in the tarball) were incorrect. See this bug for details if you're interested:

  https://bugzilla.gnome.org/show_bug.cgi?id=691807

However, when using ftsadmin install --force, I expected the command to overwrite the tarball originally uploaded for the new one. Technically, there is no difference in the git repository to warrant a new release.

When I try this, I get:

[mr@master ~]$ ftpadmin install -f tracker-0.15.3.tar.gz
Gathering information and sorting on version: ., done
Preparing installation of tracker-0.15.3.tar.gz:
ERROR: tracker-0.15.3.tar.gz already exists in the archive!

--

This looks like a bug in the script. Of course the package already exists in the archive.

The documentation says:

  -f, --force           Overwrite the original tarball

If --force is not meant for this, what is it meant for?
Comment 1 Olav Vitters 2013-03-11 21:49:18 UTC
I'll remove that option.

Note: I have scripts which download the tarball automatically. At the moment within 3 minutes of you releasing the tarball, but ideally I want to grab it within seconds. I should not be the only one doing this.

If you want to re-release a version, then IMO it should not be easy. At least it needs an email to distributor-list.
Comment 2 Martyn Russell 2013-03-12 09:16:47 UTC
(In reply to comment #1)
> I'll remove that option.
> 
> Note: I have scripts which download the tarball automatically. At the moment
> within 3 minutes of you releasing the tarball, but ideally I want to grab it
> within seconds. I should not be the only one doing this.

OK. So it looks like I have to do a new bump release then.
 
> If you want to re-release a version, then IMO it should not be easy. At least
> it needs an email to distributor-list.

This is the first time that I've ever needed to do it, but I can see a good reason for needing this option, like the case in the bug linked in comment #1. The actual code hasn't changed, it's the tarball itself that's wrong. Sadly comparing 0.15.3 to a 0.15.4 (or next version) would show 0 differences, all because the tarball was uploaded incorrectly. Are you sure I can't convince you to allow an option like this to override an existing release tarball? :)
Comment 3 Martyn Russell 2013-03-12 09:17:52 UTC
I would certainly send an email explaining the new tarball to the lists I normally forward the release to anyway.
Comment 4 Andrea Veri 2013-11-21 14:56:38 UTC
The GNOME Infrastructure Team is currently migrating its bug / issue tracker away from Bugzilla to Request Tracker and therefore all the currently open bugs have been closed and marked as OBSOLETE.

The following move will also act as a cleanup for very old and ancient tickets that were still living on Bugzilla. If your issue still hasn't been fixed as of today please report it again on the relevant RT queue.

More details about the available queues you can report the bug against can be found at https://wiki.gnome.org/Sysadmin/RequestTracker.

Thanks for your patience,

the GNOME Infrastructure Team