The PPA admin form should not allow privatisation to be changed on PPAs with packages

Bug #506203 reported by Steve McInerney
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Michael Nelson

Bug Description

The PPA admin form doesn't stop admins from privatising an existing PPA that has published packages. This is bad because it splits the repository in two, and the librarian files between the restricted and the unrestricted librarian. The private field should be disabled if the PPA has packages.

Tags: lp-soyuz ppa ui

Related branches

Revision history for this message
Julian Edwards (julian-edwards) wrote :

The real bug here is that we let PPAs that already have packages to be privatised. This is totally unsupported because it causes all of this breakage, and lots more that you can't immediately see like splitting PPA files across different librarians.

I'll update the bug description to reflect this.

Changed in soyuz:
status: New → Triaged
summary: - PPA packages in Public -> Private switch are inaccessible
+ The PPA admin form should not allow privatisation to be changed on PPAs
+ with packages
Changed in soyuz:
importance: Undecided → High
milestone: none → 10.02
tags: added: ppa ui
description: updated
Revision history for this message
Brian Thomason (brian-thomason) wrote :

Hi Julian,

I appreciate your having looked into this as I was scratching my head as to what was going on.

I understand that the easy fix is to disable the form allowing privatization of PPAs already containing packages, but hopefully in the midterm there will be a solution to do this, as it will likely come up again in the future.

Thanks!

-Brian

Revision history for this message
Julian Edwards (julian-edwards) wrote :

Hi Brian

Solving this so we *can* change the privatisation status is not easy, since we'd need to have some non-webapp process that:
 * Moves the repository to the new root directory
 * Moves files between librarians

These are both heavyweight operations, hence they can't be done "instantly" via the UI.

Because of this, I'm not yet convinced about the return on investment when:
 a) making public stuff private is a bit nonsensical; once something is public it's always public!
 b) I've only ever seen one request to make a private PPA public and that was handled manually. I think it makes sense to continue to handle it manually unless there's a high likelihood of there being many more requests.

Cheers
Julian

Revision history for this message
Brian Thomason (brian-thomason) wrote :

Fair enough if it is a lot of work. I'll try to keep them to a minimum.

And in this case, it wasn't a matter of making packages private that were once public, it was a matter of inserting new packages into the PPA that needed to be private. This will (very slowly mind you) probably become more common, but I'll just make all vendor PPAs private by default to avoid the issue.

Revision history for this message
Julian Edwards (julian-edwards) wrote : Re: [Bug 506203] Re: The PPA admin form should not allow privatisation to be changed on PPAs with packages

> I'll just make all vendor PPAs private by default to avoid the issue.

That's a wise thing to do :)

Changed in soyuz:
status: Triaged → In Progress
assignee: nobody → Michael Nelson (michael.nelson)
Revision history for this message
Michael Nelson (michael.nelson) wrote :

This landed r10415 devel (the above 280line fix and 4200 lines of related test refactoring linked on bug 523147).

Changed in soyuz:
status: In Progress → Fix Committed
Changed in soyuz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.