[Mono-bugs] [Bug 550551] New: A user's Suse Studio personal repo can get polluted and cause problems

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=550551


           Summary: A user's Suse Studio personal repo can get polluted
                    and cause problems
    Classification: Mono
           Product: Mono: Tools
           Version: MonoVS 1.0.x
          Platform: i586
        OS/Version: openSUSE 11.1
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Visual Studio Integration
        AssignedTo: jpobst at novell.com
        ReportedBy: twiest at novell.com
         QAContact: mono-bugs at lists.ximian.com
                CC: ajorgensen at novell.com, jhill at novell.com
          Found By: Component Test


Description of Problem:
A user's Suse Studio personal repo can get polluted and cause problems. I'm not
sure how we can fix this, but it's a problem that our users are going to run
into.

Since SuSE Studio always chooses the RPM with the highest version number (based
on it's solver), and because SuSE Studio always keeps around _all_ of the RPMs
that you've ever created a VM with, this means that if you ever downgrade the
version number you won't get the new (lower versioned) rpm, you'll get whatever
RPM has the highest Version number.

The only way to fix this is to go into your personal SuSE Studio repo and
remove the RPMs with the higher version number.

Luckily SuSE Studio does group the RPMs uploaded into SuSE Version and Arch
repos. So, for instance, RPMs that I've uploaded to create SLES 11 i586 VMs are
in a different repo that RPMs that I've updated to create SLES 11 x86_64 VMs.

What if a user is maintaining two versions of their software. A bug is found in
the one with the lower version number, so they need to create a new appliance
with the new package. If the two versions used the same OS / arch for their
appliances, then the user will not be able to create an appliance for the lower
version numbered RPM unless they go in and clear out the RPMs in their personal
repo.


Steps to reproduce the problem:
1. Create a new solution based on the C# winforms template project
2. Create an RPM and make sure to set the version to 2.0
3. Create an openSUSE 11.1 i586 VM with this 2.0 RPM
4. Change the version of the RPM in the MonoVS packaging stuff to 1.0
5. Create another openSUSE 11.1 i586 VM with this new 1.0 RPM
6. In the software tab, search for the package you created
7. Notice that the 2.0 version shows up and NOT the 1.0 version.
6. Build and Test drive the VM
7. Look at the installed RPM
7. Notice that the older 2.0 RPM was installed instead of the new 1.0 one.


Actual Results:
The older RPM is used.


Expected Results:
The newer one should be used, even if it's got a lower version number.


How often does this happen? 
every time

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.