[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
>Why don't you simple use a property where a IU can
>list the categories that it thinks it belongs to? I'm confused...
I don't think I was clear enough in the explanation. Consider an IU "Foo".
It may be useful to present "Foo" in different categories, depending on the repo in which Foo appears.
The current structure allows this, because the categories are built independently of "Foo." When the category metadata was designed, one of the requirements was that "Foo" should not be modified to change its categorization. Repo publishers should be able to present "Foo" in their repo in whatevery category they wish without having to alter Foo.
So... the category structure has to be independent of the IU.
When figuring out how to represent it, using an IU as convenient. However, a category has never been intended to be installable (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=229301). I realize representing it using an IU is misleading to us programmers. The UI knows that it's not truly installable, and it does play "tricks" to merge content from different repos.
>The first repository that defines a category name will block all other
>repositories using that same name.
No, it does not. That is what the UI tricks are doing - merging content into categories with the same id.
susan
![Inactive hide details for Thomas Hallgren <thomas@xxxxxxx>]()
Thomas Hallgren <thomas@xxxxxxx>
![]()
| ![]()
| ![]()
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc:
Subject: Re: [p2-dev] Categories |
Susan Franklin McCourt wrote:
>
> Hi, Thomas.
> There's been discussion of categories in the last couple of p2 calls,
> as well as some open bugs on these issues...
>
> 4 - there has been discussion for some time about the ability to
> support repo aggregators who provide their own categorization,
> independent of the publisher's view of categories. I agree it feels
> "backwards" (and in fact, makes finding uncategorized things quite
> clunky) to rely on the categories themselves to enumerate their
> content, but the intention was that aggregation and grouping for the
> same IU's could be different in different repos, and this should be
> done without having to modify the IU itself.
>
This is probably the thing that I'd consider the most problematic.
Consider the case when you install from several disparate repositories.
The first repository that defines a category name will block all other
repositories using that same name. There's no way different vendors can
agree on publishing things under a common category unless they jointly
maintain that category in a joint repository. Doesn't that defeat the
purpose of categorization? If the only purpose with the category is to
group things together in the scope of one repository, why not just use a
feature for that?
If I understood whats in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=261104 correctly, the UI
currently merges the category IU's together when they have the same ID.
To me it looks like you are using the IU's in ways that I don't think it
was intended. As the name suggests, it's something installable. Here you
merge them just to group things together in the UI and they're not
really installable. Why don't you simple use a property where a IU can
list the categories that it thinks it belongs to? I'm confused...
Regards,
Thomas Hallgren
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
