half baked idea for further baking: "fedora-ugly" repo

Marcela Mašláňová mmaslano at redhat.com
Thu Feb 13 11:32:29 UTC 2014

On 02/13/2014 11:05 AM, Tadej Janež wrote:
> On Tue, 2014-02-11 at 14:23 -0800, Toshio Kuratomi wrote:
>> I think we need to support the use-cases of both Incubator (packages here
>> are destined for Commons once the packages are polished up) and Ugly (these
>> packages are usful for Fedora End Users to have access to but the upstream
>> and downstream packaging is such that we'd never want to push them to people
>> features as is).
> +1
>> I would like to avoid having two repositories for these two use cases if one
>> repository would fit the bill.
> +1. I also think the name of the repository should reflect that. I would
> suggest something catchy, like Fedora Easy or Fedora Playground (Honza
> Horak's suggestion), or something that would go with the Rings theme,
> like Fedora Mantle (implying the main Fedora repo is Core).
>> I think that many of these things get left out in the cold if we're
>> specifying that the new repo doesn't support conflicts between the new repo
>> and the Fedora Commons repo, the Core (once we figure out how to distribute
>> that), or each other.
> I think conflicts are an important thing to figure out before we
> continue laying plans for this new repo.
> I wouldn't throw all conflicts in the same bin. For example, I think
> it's ok to bundle libraries (though it would be cool if we could somehow
> detect it automatically and know which libraries are bundled), but I
> would not be in favour of allowing package naming conflicts.
> Regarding multiple parallelly installable versions of the same packages,
> are SCLs going to give us that?
> Also, SCLs could be useful when packages have file system conflicts. On
> the other hand, would this be abusing SCLs?
It depends how hard would be to package it. I wouldn't push for SCL in 
every case.
>> We would definitely want people to know that we weren't promising security,
>> timely updates, etc... (indeed, we might want to tell people to expect
>> insecure code, packages that would languish, etc...) as there would be
>> a much higher duplication of code in this repo and likely more packages
>> which included versions that were no longer accepted upstream.
> +1.
> Tadej
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Yesterday I sent email to devel list about content and use-cases of the 
repo. No replies yet. Server WG will probably package Roles into SCL, 
but have them in main repo. Some incubating Roles might go in Playground 


More information about the env-and-stacks mailing list