Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
[1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft... [2] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft...
Marcela
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
Partly playing devil's advocate here: what is the difference then between current copr's and multiple small/individual repos?
Is it just better discoverability/filtering and ease of adding repos? If copr provided signing and repo packages would there be much difference? I guess it is possible for copr deps to be expressed as one copr repo requiring another: so kind of meta-packaging.
Actually I quite like the idea of the flexibility of a repo for (enabling) individual copr repos but just trying to understand better what it would give us. In a way I almost feel like we need both for greater flexibility, but maybe a repo of coprs and a stable ring 2 repo would be sufficient for many use-cases?
Jens
On 03/19/2014 02:30 AM, Jens Petersen wrote:
Is it just better discoverability/filtering and ease of adding repos? If copr provided signing and repo packages would there be much difference?
Yes. It is merely stating that if you want to use python-3.4 you should use bkabrda/python-3.4 which e.g was promised (by some request for playground inclusion) to be stable. Rather then some_random_user/python-3.4 which is just some one-shot project with some hackish patches.
----- Original Message -----
On 03/19/2014 02:30 AM, Jens Petersen wrote:
Is it just better discoverability/filtering and ease of adding repos? If copr provided signing and repo packages would there be much difference?
Yes. It is merely stating that if you want to use python-3.4 you should use bkabrda/python-3.4 which e.g was promised (by some request for playground inclusion) to be stable. Rather then some_random_user/python-3.4 which is just some one-shot project with some hackish patches.
Yes, this is my idea as well. Plus, as we already stated, in time the Playground repos could get some (semi-)automated reviews/sanity checks/autoQA as opposed to standard copr repos.
Slavek.
-- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
On Wed, 2014-03-19 at 10:32 -0400, Bohuslav Kabrda wrote:
----- Original Message -----
On 03/19/2014 02:30 AM, Jens Petersen wrote:
Is it just better discoverability/filtering and ease of adding repos? If copr provided signing and repo packages would there be much difference?
Yes. It is merely stating that if you want to use python-3.4 you should use bkabrda/python-3.4 which e.g was promised (by some request for playground inclusion) to be stable. Rather then some_random_user/python-3.4 which is just some one-shot project with some hackish patches.
Yes, this is my idea as well. Plus, as we already stated, in time the Playground repos could get some (semi-)automated reviews/sanity checks/autoQA as opposed to standard copr repos.
Although I support the vision of a single "big" Playground repository, I see a benefit in having this other repository concept. Maybe it could just be an "index" of "starred" COPRs that: 1) have undergone some automatic review / QA, or 2) are being (co)-maintained by the same people that (co)-maintain the software in Fedora's main repository (e.g. Slavek's python-3.4 COPR), or 3) are being (co)-maintained by provenpackagers, or ...?
Tadej
I actually like the idea of multiple small repos (joined together by a metapackage with all repos as Jens suggested). That way we will have set of repos where individual maintainers or groups of folks (like KDE guys) care to have the packages up2date and functional. I've been playing with Qt5 repo from KDE folks and I don't think we have to clone this repo or setup a new one, I would just reuse it. Also if someone would like to use playground but not get updates from one particular project (say I don't like Slavek's python repo) I can still disable only that single repo and continue playing with others.
Radek
----- Original Message -----
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
Partly playing devil's advocate here: what is the difference then between current copr's and multiple small/individual repos?
Is it just better discoverability/filtering and ease of adding repos? If copr provided signing and repo packages would there be much difference? I guess it is possible for copr deps to be expressed as one copr repo requiring another: so kind of meta-packaging.
Actually I quite like the idea of the flexibility of a repo for (enabling) individual copr repos but just trying to understand better what it would give us. In a way I almost feel like we need both for greater flexibility, but maybe a repo of coprs and a stable ring 2 repo would be sufficient for many use-cases?
Jens _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
----- Original Message -----
I actually like the idea of multiple small repos (joined together by a metapackage with all repos as Jens suggested). That way we will have set of repos where individual maintainers or groups of folks (like KDE guys) care to have the packages up2date and functional. I've been playing with Qt5 repo from KDE folks and I don't think we have to clone this repo or setup a new one, I would just reuse it. Also if someone would like to use playground but not get updates from one particular project (say I don't like Slavek's python repo) I can still disable only that single repo and continue playing with others.
Well, I'd even go further and don't call it repo but just collections of coprs, installable via Software Installer. I know, there's one (for some) huge disadvantage - not usable with Yum but for the target audience... As far as I remember, Hughsie was talking, that he's trying to figure this out for the installer.
Jaroslav
Radek
----- Original Message -----
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
Partly playing devil's advocate here: what is the difference then between current copr's and multiple small/individual repos?
Is it just better discoverability/filtering and ease of adding repos? If copr provided signing and repo packages would there be much difference? I guess it is possible for copr deps to be expressed as one copr repo requiring another: so kind of meta-packaging.
Actually I quite like the idea of the flexibility of a repo for (enabling) individual copr repos but just trying to understand better what it would give us. In a way I almost feel like we need both for greater flexibility, but maybe a repo of coprs and a stable ring 2 repo would be sufficient for many use-cases?
Jens _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
On 19. 3. 2014 at 10:39:28, Jaroslav Reznik wrote:
----- Original Message -----
I actually like the idea of multiple small repos (joined together by a metapackage with all repos as Jens suggested). That way we will have set of repos where individual maintainers or groups of folks (like KDE guys) care to have the packages up2date and functional. I've been playing with Qt5 repo from KDE folks and I don't think we have to clone this repo or setup a new one, I would just reuse it. Also if someone would like to use playground but not get updates from one particular project (say I don't like Slavek's python repo) I can still disable only that single repo and continue playing with others.
Well, I'd even go further and don't call it repo but just collections of coprs, installable via Software Installer. I know, there's one (for some) huge disadvantage - not usable with Yum but for the target audience... As far as I remember, Hughsie was talking, that he's trying to figure this out for the installer.
I also plan similar functionality to be a part of SCLv2, that is if the COPR design is sane and supports something like that.
Thanks Jan
On Wed, 2014-03-19 at 10:39 -0400, Jaroslav Reznik wrote:
I know, there's one (for some) huge disadvantage - not usable with Yum but for the target audience...
I saw a blog post about the new DNF copr plugin [1], which aims to ease the use of COPRs on a system.
Maybe some decent search functionality in the plugin could solve the issue you describe?
Tadej
On 03/20/2014 12:59 AM, Tadej Janež wrote:
Maybe some decent search functionality in the plugin could solve the issue you describe?
Search functionality will be in copr plugin few weeks. It required new API call, which landed in Copr just yesterday.
Jaroslav wrote:
Well, I'd even go further and don't call it repo but just collections of coprs, installable via Software Installer. I know, there's one (for some) huge disadvantage - not usable with Yum but for the target audience...
I don't quite follow: why no yum support? Do you mean don't provide <copr-reponame>-release rpms? (or however we would choose to name them)
Jens
----- Original Message -----
Jaroslav wrote:
Well, I'd even go further and don't call it repo but just collections of coprs, installable via Software Installer. I know, there's one (for some) huge disadvantage - not usable with Yum but for the target audience...
I don't quite follow: why no yum support? Do you mean don't provide <copr-reponame>-release rpms? (or however we would choose to name them)
I meant - Software installer would be aware of what Coprs belong to what collection. Yum/Dnf would not be (unless this feature is implemented). You would have add all Coprs from collection manually. But looks like DNF could solve, I'm going to ping Ales.
R.
Jens _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
On Wed, 2014-03-19 at 09:35 -0400, Radek Vokál wrote:
I've been playing with Qt5 repo from KDE folks and I don't think we have to clone this repo or setup a new one, I would just reuse it.
As I understand the current idea of the Playground repository, we will be reusing packages from selected COPRs. However, we will still have to clone/copy the packages since the user/group may delete them (for whatever reason), but we would still want them to be a part of the Playground repository to not disrupt our users.
Also if someone would like to use playground but not get updates from one particular project (say I don't like Slavek's python repo) I can still disable only that single repo and continue playing with others.
Hmm, couldn't you "disable" one particular COPR by just not installing any of its packages?
Tadej
On Tue, 2014-03-18 at 16:22 +0100, Marcela Mašláňová wrote:
Today was discussed whether we want one big repo or multiple small ones [1].
I hope we all agree that the general idea behind the Playground repo is to have some middle ground between current Fedora's main repo and COPRs. However, as the saying goes, the devil is in the details, i.e. we need to find out what this middle ground is.
My vision for the Playground repo is to provide a single "big" repository with a little more integration work being done at the repo level than to just provide a curated collection of multiple COPRs.
In my view, two of the main things driving the creation of the Playground repo are: 1) Some things take a very long time to get into Fedora because of the current (suboptimal) review process. 2) Some things simply cannot go into Fedora because of the current (strict) FPG.
We can solve those two things and at the same time retain one big integration point offered by the packages in the Fedora's main repository: "Users should always be able to install the latest packages from Fedora's repos regardless of what other Fedora packages are installed." [1]
For the Playground repository I would modify that to: "Users should always be able to install the latest packages from the Playground repository regardless of what other packages from the Playground repository and the Fedora's main repository are installed."
I admit this will be hard to achieve but I think this is the area where we have to do the integration work so that the users of the Playground repository don't have to do it themselves. For example, Fedora really won't make a good impression on a user that has to decipher an error message about unresolved conflicts in the transaction set when he tries to install *some cool new package*.
How to achieve this? We'll need to develop tooling that will automatically detect when there are conflicting files between multiple packages or just conflicting package names and suggest to the packager what are the possible solutions to resolve it. And in cases when a package carries an explicit Conflicts: tag, we might just flag it for manual review.
Tadej
[1] https://fedoraproject.org/wiki/Packaging:Conflicts#Conflicts
On 03/20/2014 12:24 AM, Tadej Janež wrote:
On Tue, 2014-03-18 at 16:22 +0100, Marcela Mašláňová wrote:
Today was discussed whether we want one big repo or multiple small ones [1].
I hope we all agree that the general idea behind the Playground repo is to have some middle ground between current Fedora's main repo and COPRs. However, as the saying goes, the devil is in the details, i.e. we need to find out what this middle ground is.
I concur.
My vision for the Playground repo is to provide a single "big" repository with a little more integration work being done at the repo level than to just provide a curated collection of multiple COPRs.
In my view, two of the main things driving the creation of the Playground repo are:
- Some things take a very long time to get into Fedora because of the
current (suboptimal) review process. 2) Some things simply cannot go into Fedora because of the current (strict) FPG.
We can solve those two things and at the same time retain one big integration point offered by the packages in the Fedora's main repository: "Users should always be able to install the latest packages from Fedora's repos regardless of what other Fedora packages are installed." [1]
I wouldn't fight for integration here. If you want to do integration here, then the process is not much different from inclusion of packages into rawhide.
For the Playground repository I would modify that to: "Users should always be able to install the latest packages from the Playground repository regardless of what other packages from the Playground repository and the Fedora's main repository are installed."
I disagree. Not all latest versions of packages must go through Playground repo. In some cases it might be more work than needed. I would leave it up to maintainers with dozens of packages, what they think.
I admit this will be hard to achieve but I think this is the area where we have to do the integration work so that the users of the Playground repository don't have to do it themselves. For example, Fedora really won't make a good impression on a user that has to decipher an error message about unresolved conflicts in the transaction set when he tries to install *some cool new package*.
How to achieve this? We'll need to develop tooling that will automatically detect when there are conflicting files between multiple packages or just conflicting package names and suggest to the packager what are the possible solutions to resolve it. And in cases when a package carries an explicit Conflicts: tag, we might just flag it for manual review.
I still don't buy the idea - no conflicts in repo.
Tadej
[1] https://fedoraproject.org/wiki/Packaging:Conflicts#Conflicts
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Marcela
On Thu, 2014-03-20 at 13:06 +0100, Marcela Mašláňová wrote:
I wouldn't fight for integration here. If you want to do integration here, then the process is not much different from inclusion of packages into rawhide.
I disagree. I think there is a quite substantial difference in the process. To include a package in Rawhide, it has to go through ordinary package review and adhere to the current Packaging guidelines. To include a package in the Playground repository it would have to go through (semi)automatic review and adhere to a (small) policy/guidelines set for the Playground repository.
For the Playground repository I would modify that to: "Users should always be able to install the latest packages from the Playground repository regardless of what other packages from the Playground repository and the Fedora's main repository are installed."
I disagree. Not all latest versions of packages must go through Playground repo. In some cases it might be more work than needed. I would leave it up to maintainers with dozens of packages, what they think.
What did you mean with "not all latest versions of packages must go through the Playground repository"?
I still don't buy the idea - no conflicts in repo.
Another point to consider is how to handle user queries when things conflict with each other? They will face semi-cryptic messages about unresolved dependencies/conflicts when they try to install a desired package. Or, are we aiming the Playground repository to savvy users and developers who will know what to do?
Tadej
On 03/21/2014 12:32 PM, Tadej Janež wrote:
On Thu, 2014-03-20 at 13:06 +0100, Marcela Mašláňová wrote:
I wouldn't fight for integration here. If you want to do integration here, then the process is not much different from inclusion of packages into rawhide.
I disagree. I think there is a quite substantial difference in the process. To include a package in Rawhide, it has to go through ordinary package review and adhere to the current Packaging guidelines. To include a package in the Playground repository it would have to go through (semi)automatic review and adhere to a (small) policy/guidelines set for the Playground repository.
I don't think we can avoid at least some level of integration testing in any scenario. Choosing any approach (one big/many small) repo(s) will need some basic level of checking that some package is not breaking other stuff.
Honza
For the Playground repository I would modify that to: "Users should always be able to install the latest packages from the Playground repository regardless of what other packages from the Playground repository and the Fedora's main repository are installed."
I disagree. Not all latest versions of packages must go through Playground repo. In some cases it might be more work than needed. I would leave it up to maintainers with dozens of packages, what they think.
What did you mean with "not all latest versions of packages must go through the Playground repository"?
I still don't buy the idea - no conflicts in repo.
Another point to consider is how to handle user queries when things conflict with each other? They will face semi-cryptic messages about unresolved dependencies/conflicts when they try to install a desired package. Or, are we aiming the Playground repository to savvy users and developers who will know what to do?
Tadej
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
----- Original Message -----
On 03/21/2014 12:32 PM, Tadej Janež wrote:
On Thu, 2014-03-20 at 13:06 +0100, Marcela Mašláňová wrote:
I wouldn't fight for integration here. If you want to do integration here, then the process is not much different from inclusion of packages into rawhide.
I disagree. I think there is a quite substantial difference in the process. To include a package in Rawhide, it has to go through ordinary package review and adhere to the current Packaging guidelines. To include a package in the Playground repository it would have to go through (semi)automatic review and adhere to a (small) policy/guidelines set for the Playground repository.
I don't think we can avoid at least some level of integration testing in any scenario. Choosing any approach (one big/many small) repo(s) will need some basic level of checking that some package is not breaking other stuff.
During the last Fedora QA meeting, I gave heads ups to folks, especially Tim, as he's working on Taskotron, that we would probably need some help. They seemed to be open to the idea and they are now waiting for more details.
Jaroslav
Honza
For the Playground repository I would modify that to: "Users should always be able to install the latest packages from the Playground repository regardless of what other packages from the Playground repository and the Fedora's main repository are installed."
I disagree. Not all latest versions of packages must go through Playground repo. In some cases it might be more work than needed. I would leave it up to maintainers with dozens of packages, what they think.
What did you mean with "not all latest versions of packages must go through the Playground repository"?
I still don't buy the idea - no conflicts in repo.
Another point to consider is how to handle user queries when things conflict with each other? They will face semi-cryptic messages about unresolved dependencies/conflicts when they try to install a desired package. Or, are we aiming the Playground repository to savvy users and developers who will know what to do?
Tadej
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Marcela wrote last week:
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2].
Another question: how does softwarecollections.org repos compare to our Ring 2 repos? Maybe they are also part of it like Copr repos?
And I saw discussion on epel-devel list about EPIC repo idea ("faster moving EPEL-like repo"). Are EL repos also in our scope?
Some many repos, so little time. :)
Jens
On 03/25/2014 10:02 AM, Jens Petersen wrote:
Marcela wrote last week:
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2].
Another question: how does softwarecollections.org repos compare to our Ring 2 repos? Maybe they are also part of it like Copr repos?
I would say so. The softwarecollections.org repos consume staff from Copr.
And I saw discussion on epel-devel list about EPIC repo idea ("faster moving EPEL-like repo").
My first thought - great idea, second it should be still easy to follow rules for maintainers.
Are EL repos also in our scope?
Hm, EPEL is still Fedora, so it might be true. I'm not sure who is doing EPEL. Last time I was looking for some SIG, I was pointed to nirik.
Some many repos, so little time. :)
Jens _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Marcela
On 03/18/2014 04:22 PM, Marcela Mašláňová wrote:
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
I tried to look at both options from user POV and having more little repos seems to me like a better option, since it would allow him to locate the necessary coprs easily, but he'd have to install the packages in the next step (unless dnf/yum/other tool would be able to do it in one step).
The user would also be able not to polute his list of available packages with many unneeded packages (already mentioned in [1]). This way would also use the concept of separate coprs that I like and would like to keep unbroken.
Also I don't think it is either one or the second way, we should be able to introduce a package, that would include all repositories and that way we could have both ways implemented (one big repo and many small repos as well; but we'd end up also with cons from both approaches, so it is not optimal either).
Honza
[1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft...
[2] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft...
Marcela _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
----- Original Message -----
On 03/18/2014 04:22 PM, Marcela Mašláňová wrote:
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
I tried to look at both options from user POV and having more little repos seems to me like a better option, since it would allow him to locate the necessary coprs easily, but he'd have to install the packages in the next step (unless dnf/yum/other tool would be able to do it in one step).
I talked to Mirek and it seems current support in DNF mostly allows this collections of Copr repositories. So we are almost there - what Mirek told me, it would require week, two weeks to implement it (of course, if someone would be interested in this work ;-). The same support could be added to WS Software Installer - I know Hughsie was thinking about it. Only YUM will be left out. The question how big issue is it? DNF as default targets F22 but I expect we should be able to find solution for it too.
But the whole idea is - don't reinvent wheel, use what we almost have, try it in smaller scale. If it works, extend it, if not - there's also possibility to try another round later.
Jaroslav
On 03/26/2014 06:03 AM, Jaroslav Reznik wrote:
----- Original Message -----
On 03/18/2014 04:22 PM, Marcela Mašláňová wrote:
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
I tried to look at both options from user POV and having more little repos seems to me like a better option, since it would allow him to locate the necessary coprs easily, but he'd have to install the packages in the next step (unless dnf/yum/other tool would be able to do it in one step).
I talked to Mirek and it seems current support in DNF mostly allows this collections of Copr repositories. So we are almost there - what Mirek told me, it would require week, two weeks to implement it (of course, if someone would be interested in this work ;-). The same support could be added to WS Software Installer - I know Hughsie was thinking about it. Only YUM will be left out. The question how big issue is it? DNF as default targets F22 but I expect we should be able to find solution for it too.
But the whole idea is - don't reinvent wheel, use what we almost have, try it in smaller scale. If it works, extend it, if not - there's also possibility to try another round later.
Jaroslav _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
I realize we should CC'ed hughsie long time ago. Hughsie, do you have any plans how to easily pick repositories by PK?
I still like the idea of more small repos. It's not clear to me how to check the content, but one problem at the time :)
Marcela
On 26 March 2014 18:20, Marcela Mašláňová mmaslano@redhat.com wrote:
I realize we should CC'ed hughsie long time ago. Hughsie, do you have any plans how to easily pick repositories by PK?
Well, I'm looking at this from a high level point of view. Now we have a depsolver doing SAT we can mix repos and have a lot more packages without the depsolve taking order-of-magnitude more time to complete, so technically wither is possible. The question is if we want to do that. Having lots of small repos means that you can build a layering up of products nicely, but what happens when the end user (or admin) disables a repo that provides packages that other repos depend on? Best case we stop getting updates and the packages get stuck at their present versions forever, worst case we get hacked because libssl can's be updated as it deps on a package which deps on a package that can't be solv'd.
In GNOME Software when the client "removes" a software source, all the packages previously installed from that source are removed. This prevents the problem above, but means we can only show "leaf" repos, rather than core ones like fedora or fedora-updates.
So, there's no clear-cut winner either way. I don't think it matters if you have numerous small repos or one big one, but I think the small-repos idea has to have some kind of dependency chain so you can't disable "base" and then try to install stuff from "desktop".
Richard
----- Original Message -----
On 26 March 2014 18:20, Marcela Mašláňová mmaslano@redhat.com wrote:
I realize we should CC'ed hughsie long time ago. Hughsie, do you have any plans how to easily pick repositories by PK?
Well, I'm looking at this from a high level point of view. Now we have a depsolver doing SAT we can mix repos and have a lot more packages without the depsolve taking order-of-magnitude more time to complete, so technically wither is possible. The question is if we want to do that. Having lots of small repos means that you can build a layering up of products nicely, but what happens when the end user (or admin) disables a repo that provides packages that other repos depend on? Best case we stop getting updates and the packages get stuck at their present versions forever, worst case we get hacked because libssl can's be updated as it deps on a package which deps on a package that can't be solv'd.
In GNOME Software when the client "removes" a software source, all the packages previously installed from that source are removed. This prevents the problem above, but means we can only show "leaf" repos, rather than core ones like fedora or fedora-updates.
So, there's no clear-cut winner either way. I don't think it matters if you have numerous small repos or one big one, but I think the small-repos idea has to have some kind of dependency chain so you can't disable "base" and then try to install stuff from "desktop".
I'd say these "small-repos" should not be layered on top of each other, it's just more to have a bit more fine grained control over what's in the repo.
But there were several use cases collected over time: 1. incubation - packages that will one day reach main Fedora repository, just needs some time to settle down, or maintainer wished to get more testing outside of main repo just get Copr visibility could be harder. This stuff should have some sort of higher quality packages 2. exceptions - aka Chromium. Something that's usually high quality, used for daily use on production systems but would be so hard to fulfil Fedora rules to be included in main repository/incubation repo (even it could be in incubation repository forever). 3. misc stuff with different quality/exceptations... Maybe it's really stuff for standalone Coprs...
So far we agreed on "Playground" - something you should not recommend any user to enable on production machine unless he knows what to do. As a compromise to kick the idea off.
It's definitely not going to be dozens small Copr collections but more specific use case based repository/collection of Copr repositories. Just keep it easy and simple.
Btw. for Playground as interim solution, DNF only would be ok.
Jaroslav
Richard _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
I'd say these "small-repos" should not be layered on top of each other, it's just more to have a bit more fine grained control over what's in the repo.
It is probably not a primary use-case but I don't see any reason to pre-exclude dependencies between small/copr repos. As I mentioned earlier that can implemented easily by copr-repo1.noarch requiring copr-repo2.noarch, etc. This allows copr contributors to build easily on top of each-other's work without having to share a repo directly.
Jens
On 03/26/2014 06:03 AM, Jaroslav Reznik wrote:
----- Original Message -----
On 03/18/2014 04:22 PM, Marcela Mašláňová wrote:
Today was discussed whether we want one big repo or multiple small ones [1]. Both have their pros and cons, but multiple small ones would solve most of open questions [2]. I'd like to see discussion and later votes here, because on meetings are usually only five members of our SIG.
I tried to look at both options from user POV and having more little repos seems to me like a better option, since it would allow him to locate the necessary coprs easily, but he'd have to install the packages in the next step (unless dnf/yum/other tool would be able to do it in one step).
I talked to Mirek and it seems current support in DNF mostly allows this collections of Copr repositories. So we are almost there - what Mirek told me, it would require week, two weeks to implement it (of course, if someone would be interested in this work ;-). The same support could be added to WS Software Installer - I know Hughsie was thinking about it. Only YUM will be left out. The question how big issue is it? DNF as default targets F22 but I expect we should be able to find solution for it too.
But the whole idea is - don't reinvent wheel, use what we almost have, try it in smaller scale. If it works, extend it, if not - there's also possibility to try another round later.
Jaroslav _______________________________________________ env-and-stacks mailing list env-and-stacks@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
I have great idea after discussion with Stano on IRC. Why don't we use only dnf for enablement of Playground repo? Not so many people will be interested in Playground and they are surely brave enough to install even dnf :)
Marcela
On Tue, 2014-03-25 at 18:20 +0100, Honza Horak wrote:
I tried to look at both options from user POV and having more little repos seems to me like a better option, since it would allow him to locate the necessary coprs easily, but he'd have to install the packages in the next step (unless dnf/yum/other tool would be able to do it in one step).
If understood the above paragraph correctly, the main goal you envision for the Playground repository is better discoverability and ease of adding COPRs? I wish the Playground repository also provided some (small) guarantees about packaging quality that would be enforced with (semi)automatic review of the packages.
Also I don't think it is either one or the second way, we should be able to introduce a package, that would include all repositories and that way we could have both ways implemented
In my opinion, trying to imitate "one big repo" with a package that would enable all (selected) COPRs is not going to help with the conflicts issue. If we would try to pursue the "one big repo" route, it would mean automatically checking for conflicts between existing packages and new packages submitted for inclusion in the repo and refusing to accept these packages until the conflicts are resolved. That would make the user experience better since the users wouldn't be faced with semi-cryptic messages about unresolved dependencies/conflicts when they try to install a desired package.
Tadej
env-and-stacks@lists.fedoraproject.org