Hi,
The certification level of apps in Software Center varies based on which repo is enabled or disabled. As an example, please disable all repo’s except for NethForge and check the mail app (why is it in nethforge at all) mail is certified as 1/5, and then anable the default repo, and check again, mail is certified as 4/5. Same with other apps for various repo’s.
HTH
It’s intentional. If an application is orphaned, it cannot be updated and is considered untrusted.
Additionally, if multiple repositories provide the same application, only the one from the repository with the highest priority is considered. Repository priority is determined by the alphabetical order of the repository names, with those later in the alphabet (e.g., “Z”) having higher priority than those earlier (e.g., “A”).
Meaning when the original repo is no longer available of disabled?
So how to tell from which repo the app was installed from? There could be many community repo’s eventually, not ‘just’ nethesis controlled repo’s. There are already more community repo’s (5) than Nethesis controlled repo’s (2).
Interesting, that would mean that there be no ‘competing’ repo’s or competitive apps. “I rather have the yellow apple over the green apple” is not a possible choice.
IMHO this is limiting the freedom of choice and possibilities.
How and when are community dea’s considered and against what POV? I mean, not all descisions have to be a pure business descision.
I still feel the possibilities for users (this can be linux enthousiast, admin, devs, commercial users or first time try outs) are too strictly limited. Again I would opt for a fine line Nethsesis controlled repo’s and community repo’s and leave the usage and repsonsibility of the community repo’s over the actual user.
One can break everything at any given time, no need to take away the tools, it is the ‘man’ using the tool.
That’s a good question. Currently, we don’t have this information, but it’s something we plan to work on. In ns7, RPM and YUM provide a detailed history of package operations, such as install, update, and remove. It would be useful to track these in ns8 as well.
For now, the Log page may provide some information.
Please consider the following:
Package name and version conflicts exist in the ns7 RPM world as well. You cannot install OpenSSL from RHEL and then upgrade to a different version of OpenSSL from OpenSUSE. Similarly, if two ns8 repositories provide the same application from different authors and development processes, conflicts can arise. As a community we have to avoid such conflicts.
The sysadmin has full control: they can name the repositories (assigning priorities) as desired and enable or disable repositories as needed. This is the same as in ns7.
But we live in the confined container world now. We can have many different containers with different flavours of the same app.
Applications can be named as developers choose, but using the same name for different things is counterproductive. I hope our community can collaborate to avoid unnecessary confusion.
I guess so, and obviously visa versa for there was no feedback from Nethesis on this.
I’m sorry I didn’t see it before. Thank you for pointing me to that thread.
IS it Possible or not possible to implement a Function for the Sysadmin to define Repository Priorities.
That way, If i Have
Genforge, and mrmarkuz repo
If i set, mrmarluz repo as prirotiy 1,
and genforge priority 2
then if we have 2 same apps from the 2 repos, then we have the higher priroty takes precedence.
EDIT: for neth dev
USes the same priority base you already have.
just allows a user to re-order the repos, 1,2,3 that denotes the priority.
ofcourse Officiall will always be priority 1, then the rest
Assigning priorities to repositories is already possible. Repository priority is determined by their names, sorted alphabetically, where ‘Z’ overrides ‘A’. The name is set by the sysadmin, not the developers.
For example, a sysadmin can assign the following names to ensure Genforce overrides Mrmarkuz. Note that 2 as a string greater than 1:
However, a repository priority prefix shouldn’t be necessary. As mentioned earlier, the best strategy for our community is to avoid using the same name for applications developed by different authors. There are app names available for everyone!