package reprepro
severity 477708 whistlist
retitle 477708 option to ignore request to re-add modified already existing
package version
tags 477708 + wontfix
thanks
* martin f krafft <[EMAIL PROTECTED]> [080424 20:25]:
> reprepro --basedir /home/madduck/reprepro include etch-backports
> maradns_1.3.07.08-1~bpo40+1_source.changes
> Skipping inclusion of 'maradns' '1.3.07.08-1~bpo40+1' in
> 'etch-backports|main|source', as it has already '1.3.07.08-1~bpo40+1'.
>
> Good. But this causes an error when I upload a binary-only package:
>
> reprepro --basedir /home/madduck/reprepro include etch-backports
> maradns_1.3.07.08-1~bpo40+1_i386.changes
> File "pool/main/m/maradns/maradns_1.3.07.08-1~bpo40+1_i386.deb" is already
> registered with different checksums!
> md5 expected: da4ab8f03a2e34b14c260a7a367bd1f5, got:
> daf66a030d469d7f7935ba2f543de1b1
> size expected: 518314, got: 518304
> There have been errors!
>
> I'd say the two should be consistent.
They are different, because you did something different. In the first
case you uploaded a (source) package that was already there, in the second
case you uploaded a (binary) package where another of the same name was
already there.
If you upload upload the same binary package as you already have, you
should get a similar error message like in the source case. And if you
upload a different source package of the same name and version as
already in your pool you should see a similar message like in the second
case.
(At least the tests I just did make me believe it actually does so.
If you find a case where this differs, please let me know).
> Ideally, I can chose with a command line option whether to fail or not.
Given that having two different packages with the same name and version
is always a problem (it makes it much harder to debug problems, as asking
for an installed version is not enough to know which entity of the
package is actually used, having such different entities in different
distributions with the same pool is impossible, ...) and all the work
needed to make this done (special case to look at the files while not
yet within the pool to determine its version and compare that this
early) I don't give this much chances.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
