ruby-1.9.3-rpm
ruby-1.9.3-rpm copied to clipboard
Split main package into various subpackages
Hello,
I was looking for a ruby.spec and I found your repository. I split your package into various subpackages. Take a look and if there are something wrong, please tell me that I will fix it. But for me It's ok (It's already in use in my production environment).
Hi!
Thanks for this patch, I'm still mulling over whether or not I want to merge it. My main point of hesitation is I like my single package. Can you see a way that we could provide both depending on a flag to rpmbuild or maybe checking out a branch and running rpmbuild
against the spec.
Thoughts?
I like single package too. And I see no reason to split it, keeping rpm -qa | wc -l
as low as possible not to say less clutter.
@but3k4 Ping!
Hi Imeyer, sorry for delay. So, I was thinking about your question and I don't know if it's possible. I split your main package into sub-packages because this is a rpm standard.
Please, let me know what you think about it and if I can help you with something else, please, tell me.
Regards,
Claudio.
+1 to this. A lot of packages require ruby-devel, and not splitting it causes dependency errors. They absolutely should be split.
Also, I needed this patch to get this to compile.
@myoung34 The spec says Provides: ruby-devel
, do you have a case that you can show me where it isn't being recognized? Given what you said, I'm happy to create my own branch for my unified RPM and have master be the split packages. That way users can choose what they want on their own.
@but3k4 Thoughts? ^^
splitting via branch would be a good idea. My use-case is long gone now, but splitting is best-practice overall. To support both, having 2 branches would be acceptable if fixes get made to both =)
If you don't wanna change the current branch, so, create a separate branch is the best way.
@myoung34 Yep, I would make sure to do that.
@but3k4 If you wouldn't mind rebasing your changes against master, I'll merge. :smile:
Thanks a lot!
Having it split is useful for dependency. Any news?
My update pull request 30 contains a set of useful versioned 'Provides' changes, 'Conflicts' and more version specific 'Obsoletes' that may help solve some of this. I'd rather split packages like this myself, but don't have the time to burn for RHEL 5 related components.
I use it with my tweaks to allow building the 'chefdk' software on RHEL 5.