Dne 11.4.2014 19:54, Achilleas Pipinellis napsal(a):
On 04/11/2014 08:23 PM, Allen Hewes wrote:
Vit,
I don't own any packages of anything.
I have never used the Fedora Koji system for anything but I am versed in
Koji usage b/c I have my own. Is account perms and creation synced with the
FeSCO account I created a while back? i.e. can I do scratch builds? But if the
build works in mock, there's a high probability it will work in Koji but every
now and then, that's not true.
Hmm, not 100% sure if you can do scratch builds without being sponsored
as a package. Nevertheless, I am attaching my mock config I am using.
The mock config is a good start but how would I feed dependencies into those
repositories without creating my own repository somewhere? I have been playing
around with COPR of late to build GNOME 3.12 for Fedora 19. Do you think COPR
be used for this process? Also, I could put off worrying about this until I
come across packages which have these dependencies.
Since this is just a rebuild (using the same version as is), all
dependencies will be in rawhide and already met.
Yes, dependencies are met.
But to answer your question, you have two options how to install
additional dependencies into mock:
1) You can update the config file and add there some local repository.
2) If there is not much dependencies, you can install them into mock
manually (mock --install mydependency.rpm), but then you have to always
use --no-clean option, otherwise the buildroot will be recreated from
scratch and the dependency lost.
Also, you are missing my favorite: bundler. You'll need updated Thor and
rpsec 3.0.0.beta2 for it to pass its tests.
Bundler has no binary extension, therefore it is not on the list. But
there might be some updates needed.
Ah, OK that explains a lot, ext's only in the etherpad/PiratePad list.
Let's take JSON for instance. You have JSON 1.7.7 listed in etherpad/PiratePad
but there's newer versions (1.8.1).
json is not that good example, since Ruby ships json as a subpackage.
They are overlapped with the standalone version.
As part of this process, do want updates? Or just updates to make things
(test suites) run for the combination of Ruby/RubyGems/gem targeting Fedora 21?
If you'd update JSON, you'd update json_pure and multi_json. Are those included
in this process? Or is the goal to get what's in that list built against Ruby
2.1.1 / RubyGems 2.2.2?
I guess we go first with the rebuild and then with any updates.
Well, less changes is better, but otherwise there is no general answer.
But here it is how I see it:
1) When I am rebuilding my package, I might consider update to the
latest version, since I am maintainer and I'd need to do it anyway.
2) I update the package, if I know that there were some compatibility
fixes and I know I don't break any dependency. I might decide to
backport the patch otherwise, if the changes were not too invasive.
3) Otherwise, I try to not change too much, since it is maintainers
decision, what version is in Fedora.
Vít
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
