you can see in http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/updates/ that we have 2 different versions of putty in the core/updates media for Mageia 1. Is it a bug from the script that moves the packages to main and failed to remove the older one ?
Nothing changed, so far [ ] putty-0.61-0.1.mga1.i586.rpm 13-Jul-2011 19:04 618K [ ] putty-0.61-1.1.mga1.i586.rpm 30-Jul-2011 00:11 619K
CC: (none) => marja11
it seems no older versions are removed at all, look at e.g firefox (nluug mirror): File:firefox-6.0-1.1.mga1.i586.rpm 12621 KB 20/08/11 23:59:00 File:firefox-6.0.1-1.2.mga1.i586.rpm 12622 KB 01/09/11 00:02:00 File:firefox-6.0.2-0.1.mga1.i586.rpm 12618 KB 09/09/11 09:52:00 File:firefox-7.0.1-0.1.mga1.i586.rpm 12373 KB 30/09/11 02:30:00 File:firefox-8.0.1-0.4.mga1.i586.rpm 13398 KB 25/11/11 01:17:00 File:firefox-9.0.1-0.1.mga1.i586.rpm 13950 KB 22/12/11 03:51:00 same is true for packages in non-free and tainted repositories @ sysadmin If this is wanted behaviour, please explain and close this bug. If it isn't, please set status to ASSIGNED
Summary: putty is present in twice in updates => Older updates are not removed from updates repositories when a newer update becomes available
Well... The idea was to be able to do regression testing... And before someone says that we have the same info in svn, it's not entirely true. This is because stuff in svn has to be rebuilt in order to create rpms to install, wich may not produce the same results as the initial packages as some libs or packages might have been updated in between... So... Question becomes... do we want to be able to roll back / do regression testing ?
CC: (none) => tmb
I think keeping the possibility to do roll back would be nice. Alternatively, old updates could be moved to a separate directory if it's causing problem staying in the same repository. Or rpmdrake can be changed to display only the latest version of each package if this is the problem.
CC: (none) => boklm
why not make like mdv ? see my duplicate
*** Bug 3236 has been marked as a duplicate of this bug. ***
CC: (none) => manuel
Why should we do like mandriva ?
(In reply to comment #7) > Why should we do like mandriva ? Because I have never see somebody using the old update for testing regression. (except for the kernel, so same as in mdv) (For the QA it's different since the packages are updates and in testing) And that bring more issues than it solves
CC: manuel => (none)
(In reply to comment #8) > (In reply to comment #7) > > Why should we do like mandriva ? > > Because I have never see somebody using the old update for testing regression. > (except for the kernel, so same as in mdv) > (For the QA it's different since the packages are updates and in testing) It doesn't mean nobody wants them. > > And that bring more issues than it solves But you still don't explain what are those issues and why my proposals don't solve them ...
oh sorry I have not seen comment 4, yep why not
CC: (none) => mailinglistsduraph
I agree with comment #4. Having the old updates "somewhere" can be nice, but removing them from the updates media would be great.
Well, if we move the rpms, we need to hardlink the rpms so rpms dont have to be redownloaded by the mirrors. (the hardlinking should also be done for updates_testing -> updates move... iirc misc had some idea on this layout...)
(In reply to comment #12) > Well, if we move the rpms, we need to hardlink the rpms so rpms dont have to be > redownloaded by the mirrors. > > (the hardlinking should also be done for updates_testing -> updates move... > iirc misc had some idea on this layout...) cc'ing misc (or is that not needed because he always reads all sysadmin bugs?)
CC: (none) => misc
Closing as it's intentional
Status: NEW => RESOLVEDResolution: (none) => FIXED
better status then
Resolution: FIXED => WONTFIX
Wouldn't it be better to say INVALID since it is intended behavior, instead of WONTFIX, which, if I understand correctly, implies that it is valid but not worth fixing ? (I didn't change the status)
CC: (none) => andre999mga
(In reply to comment #16) > Wouldn't it be better to say INVALID since it is intended behavior, > instead of WONTFIX, which, if I understand correctly, implies that it is valid > but not worth fixing ? > > (I didn't change the status) There was still some discussion about the feature in this report. If it had been invalid, there would not have been a discussion and it would probably have been closed in august 2011
CC: boklm => (none)