[Rpm-ecosystem] some thoughts on cooker RPM future and ambitions, [FORKSOAPv3]
ngompa13 at gmail.com
Sat Jun 20 04:34:53 UTC 2015
I don't know too much about this, but I'm somewhat curious... What features
in RPM 5 do you use? I don't even know what RPM5 supports that RPM.org
doesn't. Aside from XAR, %track, and various removals/"cleanups", I don't
know of anything in rpm5 that isn't in RPM.org.
I guess the better question is: what functionality do you need to be able
to use RPM.org rpm in your distribution?
On Fri, Jun 19, 2015 at 6:47 AM, Per Øyvind Karlsen <proyvind at moondrake.org>
> I'm forwarding parts of some thought rambling on the cooker list, with
> some extra commenting:
> Second major and likely most controversial item on my list is RPM...
> Considering the advantage we had by having free playground within the RPM
> project and better collaboration with other distros, this hasn't been the
> case for years now due to diffficult upstream..
> We considered (together with PLD) first just maintaining a cvs git clone
> repo of rpm5.org where we could follow upstream and do our own work in
> common branches again where we pulled it all in easily.
> Then we considered perhaps fork rpm5 and gradually transform it to become
> compatible with rpm.org, but the heavy amounts of refactoring done within
> rpm.org makes this a very time consuming, tedious and wasteful job...
> So easier is it that we move back to rpm.org, ie. with their
> distro-ecosystem (orwhatever the list was named), most other distros of
> interest that's still around and having an interest in the golden arch
> (that I actually was hired initially for working on, as part of my master
> studies), namely a cleaner, saner, easier, more automatic, more compatible
> with far less maintenance for the RPM distros to finally share, just like
> .deb based distros has been since the early morning...
> So I have like over 300 patches maintained locally since 2011 with pretty
> much all of my work which hasn't gone upstream meanwhile and all the work
> invested into it earlier over the years before my cvs commit access was cut
> off back in nov 2011.
> So I have quite a large and lonely task cut out for me this time, only
> help I'm making some hopes of is PLD helping porting parts of their
> relevant code and functionality parts to rpm.org...
> If anyone would like to help me out with the job, even rookie apprentices
> would be accepted, please let me know! ;)
> So yes, for the next release (not upcoming), the official plan of mine
> (probably a bit perplexing to some;) is for us to move back to rpm.org...
> Even if the road seemed right at the time, sticking by important
> decissions when everything speaks against it and virtually nothing for it
> now, several years later, we need to pick a road again, this time the other
> seems the right one, even if it means having to carry with us and adapt a
> lot of work on such a critical component and decission. Of course far less
> work to stubbornly stick with a former decission and looking far less unapt
> as well by changing a course of such great controversy back then, me being
> the main proponent of...
> With some Vulcan logic applied, ~reversing decission is not very
> problematic.. ;)
> I sure hope there can be some interest and other potential rpm.org devels
> which would have interest in helping us move along on our way to rpm.org
> and welcome us... ;)
> Per Øyvind
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-ecosystem