* Ryan Hass <[email protected]> [090310 00:42]:
> I am not suggesting that reprepro is doing anything incorrectly; in fact
> I think reprepro is doing everything correctly in this instance.
> Nevertheless, it still would be a nice feature if I had a way I could
> explicitly tell reprepro, "I know the checksums won't match -- so just
> this one time, ignore the checksums and reprocess the package(s)
> anyway." (--ignore=previouslyuploaded?) And when a user uses the
> option, it should also complain endlessly about how bad it is, and the
> potential repercussions from using the argument.
>
> That's my two cents worth anyway.
My POV:
Current situation:
before readding it, you need to remove the old package (i.e. one remove
call or one removesrc if you want all packages generated from one source
or version).
i.e. one extra call to get it done (assuming it is only in one
distribution, otherwise another time for the others).
(And assuming no special Tracking keeping the old files).
Situation with such a --ignore=alreadysomefilewithdifferentchecksum:
- instead of one extra command, one needs another option to be given.
- Adding huge amounts of code rarely tested:
- the code has to check no other distribution has that file already,
then either error out or do more complicated things. (which would
be a new way to check, as yet a "still listed anywhere" is all that
is ever checked, i.e. code to filter out the current distribution,
taking into account where it is to be added (as one include command
might be restricted to a specific architecture but an architecture
all package also be in another part).
- new code to delete and forget the file. Usual workflow is to remember
all unreferenced files and delete them after all index files are
deleted (so that what is listed in those files can still be
retrieved). Even if not caring for Packages/Sources some short time not
listing valid things, what to do in case of error? And even if not
caring about what can happen if there is an error, it still needs new
code to delete a file out of the row (or making sure the existing code
is able to do that without some double-free or other strange things).
- what happens on error? should the old package be restored (almost
impossible) or should one end up with no package? ...
I don't say having multiple dfferent files with the same name is too bad
to be supported. But it's my opinion it is too bad to add such many code
for it, especially as it would add all kind of new corner cases where
the bugs usually like to hide and dwell.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
