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