U tell us " ...Silently overwriting files is not a sound practice,
because the files are almost always not the same, so overwriting them
would make for even worse bugs."
I agree is not a good practice to silently kill non convenient output
-but- and is a BIG but which in many cases is not considered .. is to
obvious, let's talk a bit about this bug on the last 2 months ... in 99%
of last cases ( as on my experience ) was the same file name and version.
If you read carefully what I wrote there about file control ( there are
few methods - including parsing file content [as brute force] ) you can
realize that must be not so hard to find a method to see if is the same
file with the same content - OR not.
Now - if is the same file - the same content - I don't see the reason to
not overwrite. ????
So I not recommend that as a best practice - but if we have an evidence
- why we should stuck on the problem instead of going forward.
Now the second point. If is not the same file -> User can choose what to
do. OR if we don't consider here so smart users - then a rule (or more)
must be defined ( regarding the same filename => to keep the bigger
version / to keep the larger file / or some... ).
Enfin - this can be good for both parts - for the distro and for the
independent programmer. If you made a program distributed by others you
will enjoy idea to put a RULE file on your package - that can be
interpreted by the mister "Update Manager" - to see what he can do in
any case. It's about a simple file where -> case 1 -> do that, case 2 ->
overwrite, case 3 -> delete older file put the newest, case 4 -> phone
home ...etc.
That's the point - not to ignore this bug ( is too often repeated,
search bug reports from the last 2 years ...). So please consider a
possible solution eventually ONLY for the case where we have SAME
VERSION - SAME NAME - SAME CONTENT ( generally python scripts from
different sources put the same files in site).
An we just walk forward a bit.
..On my opinion of course.
Anyway, that's my message -> from time to time is good to go somewhere
on a higher point to see what's here down -> just to not forget the big
picture.
Steve Langasek wrote:
> Folks,
>
> This bug is not about kernel issues, and it's been fixed in hardy.
> Please try to upgrade to the most recent version of the affected
> packages; there should be no need to follow up to this bug report unless
> you are still having problems upgrading the named package.
>
> Sorin, you are mistaken about this not being an OpenOffice.org bug. It
> is; the packaging system's behavior when two packages have conflicting
> files is not spurious, it is a carefully considered design decision
> which is crucial to the reliability of the running system. File
> overlaps unfortunately do happen from time to time in development
> releases, but these are always bugs in the packages in question that
> need to be resolved before we release - and we have a report that helps
> us identify file conflicts so we can do exactly that. Silently
> overwriting files is not a sound practice, because the files are almost
> always not the same, so overwriting them would make for even worse bugs.
>
ok Steve,
U tell us " ...Silently overwriting files is not a sound practice,
because the files are almost always not the same, so overwriting them
would make for even worse bugs."
I agree is not a good practice to silently kill non convenient output
-but- and is a BIG but which in many cases is not considered .. is to
obvious, let's talk a bit about this bug on the last 2 months ... in 99%
of last cases ( as on my experience ) was the same file name and version.
If you read carefully what I wrote there about file control ( there are
few methods - including parsing file content [as brute force] ) you can
realize that must be not so hard to find a method to see if is the same
file with the same content - OR not.
Now - if is the same file - the same content - I don't see the reason to
not overwrite. ????
So I not recommend that as a best practice - but if we have an evidence
- why we should stuck on the problem instead of going forward.
Now the second point. If is not the same file -> User can choose what to
do. OR if we don't consider here so smart users - then a rule (or more)
must be defined ( regarding the same filename => to keep the bigger
version / to keep the larger file / or some... ).
Enfin - this can be good for both parts - for the distro and for the
independent programmer. If you made a program distributed by others you
will enjoy idea to put a RULE file on your package - that can be
interpreted by the mister "Update Manager" - to see what he can do in
any case. It's about a simple file where -> case 1 -> do that, case 2 ->
overwrite, case 3 -> delete older file put the newest, case 4 -> phone
home ...etc.
That's the point - not to ignore this bug ( is too often repeated,
search bug reports from the last 2 years ...). So please consider a
possible solution eventually ONLY for the case where we have SAME
VERSION - SAME NAME - SAME CONTENT ( generally python scripts from
different sources put the same files in site).
An we just walk forward a bit.
..On my opinion of course.
Anyway, that's my message -> from time to time is good to go somewhere
on a higher point to see what's here down -> just to not forget the big
picture.
Steve Langasek wrote:
> Folks,
>
> This bug is not about kernel issues, and it's been fixed in hardy.
> Please try to upgrade to the most recent version of the affected
> packages; there should be no need to follow up to this bug report unless
> you are still having problems upgrading the named package.
>
> Sorin, you are mistaken about this not being an OpenOffice.org bug. It
> is; the packaging system's behavior when two packages have conflicting
> files is not spurious, it is a carefully considered design decision
> which is crucial to the reliability of the running system. File
> overlaps unfortunately do happen from time to time in development
> releases, but these are always bugs in the packages in question that
> need to be resolved before we release - and we have a report that helps
> us identify file conflicts so we can do exactly that. Silently
> overwriting files is not a sound practice, because the files are almost
> always not the same, so overwriting them would make for even worse bugs.
>