Fedora.next in 2014 -- Big Picture and Themes

Aleksandar Kurtakov akurtako at redhat.com
Sun Jan 26 11:26:32 UTC 2014

----- Original Message -----
> From: "Alec Leamas" <leamas.alec at gmail.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Sunday, January 26, 2014 11:22:36 AM
> Subject: Re: Fedora.next in 2014 -- Big Picture and Themes
> On 1/25/14, Adam Williamson <awilliam at redhat.com> wrote:
> > On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:
> >
> >
> >> After hacking a simple tool which provides a GUI for a repository file
> >> it's possible to create repository packages complete with  desktop and
> >> appdata file. I have some 5-10 such repository packages under way, my
> >> plan is to push them into rpmfusion.
> >
> > http://rpmfusion.org/Contributors#Read_the_packaging_guidelines
> I know this is controversial. I've also heard some rumours about
> Fedora using something they call "Packaging Guidelines". Has anyone
> some  information  on this topic? ;)
> Can we just for the sake of discussion leave this formal side of it, for now?
> > So I found this point interesting in thinking about these issues this
> > morning. There was a post of Hughesie's (I think) in another thread
> > which was also illuminating: it suggested the design of Software is to
> > be a generic 'software' installer - to provide as much 'software' from
> > as many sources as possible, under the 'it's all just software' theory,
> > I guess.
> >
> > I think the assumption that this is obviously the right design is
> > interesting, because I strongly disagree - not just for legal or policy
> > reasons, but because that's most definitely *not* what I want. I don't
> > want a 'greedy' software installer that just finds every piece of crap
> > on the internet and offers it to me. I appreciate the curation that
> I don't know if this is  Hughesie's vision. Anyway, it's certainly not
> mine. Adding whatever software available out there to the repos is a
> Bad Idea. Agreed
> That said,, IMHO  we actually need  to be better on delivering what
> people need. Some of this is not in Fedora's repos. This is already
> acknowledged here and there. E. g., rpmfusion has  list of
> repositories which are known to work with rpmfusion [1]. For fedora,
> we have e. g. jpackage, which is stated s compatible in the Java GL.

I feel obligated to comment on this. JPackage and Fedora have taken different routes years ago and installing JPackage rpm on top of Fedora will likely break Fedora packages due to:
* additional OSGi metadata Fedora ships but JPackage doesn't
* different places of maven pom and depmap changes
* different major versions of the same package (aka maven package in JPackage was 1.x (last I checked) but in Fedora it's 3.x) and etc.

Would you please point to a place where jpackage is stated as compatible? This is probably a legacy page which needs to be updated with current state of affairs so people don't think they can mix and match freely.

Alexander Kurtakov
Red Hat Eclipse team

> I'm trying to find some middle ground here. Instead of just enabling
> repos, perhaps when installing something else, I'm trying  a process
> where each and every repository added is packaged separately. Hence,
> here is also  separate review for each repository. And even if
> installed, it's not enabled until l explicitly configured by user..
> I see all the problems when using things like pip, gem etc. However,
> this is not anything like this. It's about letting users install
> carefully selected repositories which are known to work with Fedora.
> Doing it this way, we also create a difference to other repositories
> which are not endorsed.  Also this is something we need badly IMHO.
> It's also  task which naturally belongs to rpmfusion, mostly the
> non-free section.
> --alec.
> [1] http://rpmfusion.org/FedoraThirdPartyRepos
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

More information about the devel mailing list