Shawn Walker wrote:
jmr wrote:
Shawn Walker wrote:
There are two different cases here:
1) update of existing authority
- as discussed previously, if an existing authority is found to have
the same origin_url as that in the .p5i file, it assumed to be the
same authority and some of its information will be updated with the
information from the .p5i file (such as the list of origin_urls,
mirror_urls, etc.)
Ok how is this update to be handled?
I assume we surface the udpates to the user by telling them the
authority information has changed (in an Update Authority dialog) and
do they want to update it? If so we need to know from the returned
Authority Info object that it has updates.
There will be a way to tell if the returned AuthorityInfo object is
for a new or existing authority. I still need to write a summary up,
so let me do that first.
Great, no problems, I'm working away on the UI at present and using an
api wrapper with stub data to simulate things, whilst I get the logic
flow and dialog sequence working. I can send you on a workspace at the
end of the week so you can see how I'm using it.
2) addition of new authority
- if the origin_url in the .p5i file doesn't match any existing
authority, but the name conflicts, the gui will handle this
inherently since it always prompts the user to add/update the
repository while the cli will simply fail letting the user know why
it can't proceed
Yep that was the plan, I'd like to do what the Manage Repo dialog
does and if the Name for the New Authority is in conflict have a
label in red below the Name and URL fields indicating the problem to
the user so they can change it.
Please don't rely on colour alone to convey this information. It
won't mean much to colour-blind users.
Good point at the minute we output the warning in red, we could change
it if the user is using an accessible theme.
Yes, they should not be able to change the name. Refer to Stephen's
original email on the proposed authority/0 operation [1].
I assume you mean user can't change the name of a registered
authority on the system, only when adding a new one.
This does create an interesting problem. If two repositories lay
claim to the same authority name, or later update their authority
information, an unresolvable collision is going to occur.
Yep - that's what was puzzling me a bit about this. I thought the
authority can suggest a name, but the user needs to be able control the
name of the authority on their system. Will authority nicknames be the
way around this? So two authorities may have the same name but different
nicknames on the user system.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
