In Fedora and EPEL we have the qpid-cpp package (which I spoke about in an email last week) for all supported version of Fedora and for EL7 (can't do EL5/6 for the reasons mentioned in that previous email).
This week we discussed the idea of providing CentOS specific packages, starting with CentOS 7. In RHEL we have product packages, this would be something separate from what we would be doing as a product.
What would be the process for doing something like this?
On 05/13/2014 06:52 PM, Darryl L. Pierce wrote:
In Fedora and EPEL we have the qpid-cpp package (which I spoke about in an email last week) for all supported version of Fedora and for EL7 (can't do EL5/6 for the reasons mentioned in that previous email).
This week we discussed the idea of providing CentOS specific packages, starting with CentOS 7. In RHEL we have product packages, this would be something separate from what we would be doing as a product.
What would be the process for doing something like this?
the easy way of doing this would be to drop it into the Plus repo, that allows anything ( including stuff that over writes and replaces components from inside the base os repos ). however, that means that any other code that requires or benefits from the newer qpid would need to rely on the Plus repo ( and thereby potentially expose all packages, not just qpid, to the install ). Unless some sort of includepkg / excludepkg is done ( is messy, but many people can live with it ).
With that in mind, what sort of use cases are you trying to target - i dont think we really quantified that in the prev thread.
On Tue, May 13, 2014 at 09:01:53PM +0100, Karanbir Singh wrote:
the easy way of doing this would be to drop it into the Plus repo, that allows anything ( including stuff that over writes and replaces components from inside the base os repos ). however, that means that any other code that requires or benefits from the newer qpid would need to rely on the Plus repo ( and thereby potentially expose all packages, not just qpid, to the install ). Unless some sort of includepkg / excludepkg is done ( is messy, but many people can live with it ).
With that in mind, what sort of use cases are you trying to target - i dont think we really quantified that in the prev thread.
The general use cases are projects, such as Open Stack, that are targeting CentOS and who would want to use an AMQP 1.0 messaging interface, like Open Stack.
We're also of course looking for more avenues for adoption of the Qpid and Proton projects and AMQP as a standard.
But these newer versions are not really CentOS-only? They could be used with RHEL if someone wanted/needed them?
Perhaps point users to the newer versions in the OpenStack (RDO) repos? Or create a separate qpid repo where newer versions can always be had (for use with either CentOS or RHEL)?
Seems cleaner (IMHO) than muddling the packages with a general repo like centos-plus.
Maybe the question is whether CentOS is providing a general solution for hosting repositories for newer-than-rhel packages?
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Darryl L. Pierce Sent: Tuesday, May 13, 2014 1:28 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Creating a CentOS-only package
On Tue, May 13, 2014 at 09:01:53PM +0100, Karanbir Singh wrote:
the easy way of doing this would be to drop it into the Plus repo, that allows anything ( including stuff that over writes and replaces components from inside the base os repos ). however, that means that any other code that requires or benefits from the newer qpid would need to rely on the Plus repo ( and thereby potentially expose all packages, not just qpid, to the install ). Unless some sort of includepkg / excludepkg is done ( is messy, but many people can live
with it ).
With that in mind, what sort of use cases are you trying to target -
i
dont think we really quantified that in the prev thread.
The general use cases are projects, such as Open Stack, that are targeting CentOS and who would want to use an AMQP 1.0 messaging interface, like Open Stack.
We're also of course looking for more avenues for adoption of the Qpid and Proton projects and AMQP as a standard.
-- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On 05/13/2014 09:39 PM, Kay Williams wrote:
But these newer versions are not really CentOS-only? They could be used with RHEL if someone wanted/needed them?
Perhaps point users to the newer versions in the OpenStack (RDO) repos? Or create a separate qpid repo where newer versions can always be had (for use with either CentOS or RHEL)?
Seems cleaner (IMHO) than muddling the packages with a general repo like centos-plus.
Maybe the question is whether CentOS is providing a general solution for hosting repositories for newer-than-rhel packages?
thats what Plus is for - a generic repo, the SIGs can chose to run their own if they want
Perhaps an 'epel-plus' repo would make sense (someday)? Or an epel service for hosting misc repos for newer-than-rhel packages.
Not a big deal, just mulling that the qpid packages are not centos-specific (sorry, I know this is the centos-devel mailing list)...
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Karanbir Singh Sent: Tuesday, May 13, 2014 1:55 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Creating a CentOS-only package
On 05/13/2014 09:39 PM, Kay Williams wrote:
But these newer versions are not really CentOS-only? They could be used with RHEL if someone wanted/needed them?
Perhaps point users to the newer versions in the OpenStack (RDO) repos? Or create a separate qpid repo where newer versions can always be had (for use with either CentOS or RHEL)?
Seems cleaner (IMHO) than muddling the packages with a general repo like centos-plus.
Maybe the question is whether CentOS is providing a general solution for hosting repositories for newer-than-rhel packages?
thats what Plus is for - a generic repo, the SIGs can chose to run their own if they want
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/13/2014 02:59 PM, Kay Williams wrote:
Perhaps an 'epel-plus' repo would make sense (someday)? Or an epel service for hosting misc repos for newer-than-rhel packages.
Not a big deal, just mulling that the qpid packages are not centos-specific (sorry, I know this is the centos-devel mailing list)...
Well, the idea is definitely to provide "a general solution for hosting repositories for newer-than-RHEL-packages", if you accept that as a description for what SIG variants do.
In discussions with Fedora folks, everyone seems fine with EPEL sticking to it's original mission (and accepted brand.) There have been discussion in Fedora for something Robyn calls EPIC (Extra Packages for Infrastructure and Cloud), which is somewhat what you describe - items that are newer and faster-moving.
Regardless, I think the first part stands - CentOS variant SIGs are able to maintain newer-than-RHEL packages in their own repos. If they want/need to share maintainership with another SIG, then all need to decide which SIG has the package and maintain it as if in a higher tier, meaning >1 can rely upon it.
- - Karsten
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Karanbir Singh Sent: Tuesday, May 13, 2014 1:55 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Creating a CentOS-only package
On 05/13/2014 09:39 PM, Kay Williams wrote:
But these newer versions are not really CentOS-only? They could be used with RHEL if someone wanted/needed them?
Perhaps point users to the newer versions in the OpenStack (RDO) repos? Or create a separate qpid repo where newer versions can always be had (for use with either CentOS or RHEL)?
Seems cleaner (IMHO) than muddling the packages with a general repo like centos-plus.
Maybe the question is whether CentOS is providing a general solution for hosting repositories for newer-than-rhel packages?
thats what Plus is for - a generic repo, the SIGs can chose to run their own if they want
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
- -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Thu, May 15, 2014 at 04:08:24PM -0700, Karsten Wade wrote:
In discussions with Fedora folks, everyone seems fine with EPEL sticking to it's original mission (and accepted brand.) There have been discussion in Fedora for something Robyn calls EPIC (Extra Packages for Infrastructure and Cloud), which is somewhat what you describe - items that are newer and faster-moving.
I think everyone likes the basic EPIC idea. It's mostly waiting for some people to work on it. If you're interested, the EPEL devel mailing list https://lists.fedoraproject.org/mailman/listinfo/epel-devel is probably the best place to discuss it. I'd really love to see some Fedora/CentOS collaboration in this area.
On Tue, May 13, 2014 at 02:59:02PM -0700, Kay Williams wrote:
Perhaps an 'epel-plus' repo would make sense (someday)? Or an epel service for hosting misc repos for newer-than-rhel packages.
You could use Fedora's Copr service for exactly this -- it can build against EL 5, 6, and 7.
Basically, you just upload SRPMs, check what you want to build against, and a usable repo comes out. See http://copr.fedoraproject.org/ or this blog post http://bkabrda.wordpress.com/2013/02/08/introducing-copr-build-system/ . The only restrictions are that it has to be open source and legal for Fedora to distribute.
In Fedora, there are some dnf (experimental branch of a next-generation yum) plugins which make searching easier, and work on a "Playground", an aggregated set of coprs that agree to play nicely together. Some of that could happen for CentOS as well with yum plugins (I don't think there's really anything special about dnf here it just happens that that's what was made.)
I like the copr (Cool Other Package Repositories) direction, and agree with Matt's comment that it would be great to see Fedora/CentOS collaboration in this area.
The general points are that -
* users will occasionally have a need for newer versions of software than are officially supported by redhat
* making newer software versions available in a single repository (e.g. centos-plus) quickly becomes messy because users may not want/trust every new thing in that repository, and then they have to use includepkgs/excludepkgs in yum repo definitions to limit what they see. It's cleaner/easier to add/remove repos.
* in most cases, these newer software versions are not distro specific, i.e. they will work across rhel, centos, scientific, oracle, ....
* t'would be a shame to end up with two slightly different ways of accomplishing similar goals (coprs for fedora/epel, SIG repos for centos).
But I'm just one voice...
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Matthew Miller Sent: Thursday, May 15, 2014 5:27 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Creating a CentOS-only package
On Tue, May 13, 2014 at 02:59:02PM -0700, Kay Williams wrote:
Perhaps an 'epel-plus' repo would make sense (someday)? Or an epel service for hosting misc repos for newer-than-rhel packages.
You could use Fedora's Copr service for exactly this -- it can build against EL 5, 6, and 7.
Basically, you just upload SRPMs, check what you want to build against, and a usable repo comes out. See http://copr.fedoraproject.org/ or this blog post http://bkabrda.wordpress.com/2013/02/08/introducing-copr- build-system/ . The only restrictions are that it has to be open source and legal for Fedora to distribute.
In Fedora, there are some dnf (experimental branch of a next-generation yum) plugins which make searching easier, and work on a "Playground", an aggregated set of coprs that agree to play nicely together. Some of that could happen for CentOS as well with yum plugins (I don't think there's really anything special about dnf here it just happens that that's what was made.)
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 05/17/2014 12:01 AM, Kay Williams wrote:
- making newer software versions available in a single repository (e.g.
centos-plus) quickly becomes messy because users may not want/trust every new thing in that repository, and then they have to use includepkgs/excludepkgs in yum repo definitions to limit what they see. It's cleaner/easier to add/remove repos.
but the flip side is that if components arent consolidating the user experience, there is no assurance and no relationship with anything else. And this hurts from both the top end of the stack, user facing ui apps, and from the bottom end infra or system libs, in this case qpid.
Working with a single consolidated ( or maybe a few consolidated) repos means that people are unable to arbitarily 'transmorgify', without first setting some level of expectation with other components that might rely on a specific state.
Packaging is hard, sure - and it gets dramatically harder when executing without a policy framework. The includepkg / exclude process is also not easy, neither is the costs nor priorities, they all come with their own wins and pains.
Also worth noting is that SIG's dont map to repos - many ( most so far ) are likely going to opt to deliver into a common set of repos, making it easier for others to consume components, specially the infra level SIGs like Virt / Storage etc. So we need to address this issue either way, sooner the better
Also, top posting :(
On Fri, May 16, 2014 at 6:10 PM, Karanbir Singh mail-lists@karan.org wrote:
Packaging is hard, sure - and it gets dramatically harder when executing without a policy framework. The includepkg / exclude process is also not easy, neither is the costs nor priorities, they all come with their own wins and pains.
Also worth noting is that SIG's dont map to repos - many ( most so far ) are likely going to opt to deliver into a common set of repos, making it easier for others to consume components, specially the infra level SIGs like Virt / Storage etc. So we need to address this issue either way, sooner the better
I've always thought that package lists should be the thing with ultimate control. That is, a package list should be able to specify both the repo and version for every package that should be installed. That would mean a SIG just has to publish a list of packages and add anything unique to _some_ repo. Anyone consuming such a list would be assured that they were only using packages that had previously been installed and tested together. You'd need some changes to yum to respect the repo specification (which would avoid a lot of breakage in its own right), a tool to export the list from a working, tested instance (so you aren't just making them up from guesswork), and report differences between the current install and a list, and probably a tool to spin an iso with packages included for offline installs. Oh, and some syntax in the list to indicate repo changes and replaced and dropped packages.
As side effects, repos need minimal coordination, and installs/updates become repeatable. And the stuff you pass around is just human-understandable text, not special-purpose code that only works with one version of one tool in one distribution and needing specially build repositories with subsets of packages.
On 05/13/2014 09:27 PM, Darryl L. Pierce wrote:
With that in mind, what sort of use cases are you trying to target - i dont think we really quantified that in the prev thread.
The general use cases are projects, such as Open Stack, that are targeting CentOS and who would want to use an AMQP 1.0 messaging interface, like Open Stack.
We're also of course looking for more avenues for adoption of the Qpid and Proton projects and AMQP as a standard.
for now, lets try and get these into the Plus repos then.
On Tue, May 13, 2014 at 09:54:24PM +0100, Karanbir Singh wrote:
On 05/13/2014 09:27 PM, Darryl L. Pierce wrote:
With that in mind, what sort of use cases are you trying to target - i dont think we really quantified that in the prev thread.
The general use cases are projects, such as Open Stack, that are targeting CentOS and who would want to use an AMQP 1.0 messaging interface, like Open Stack.
We're also of course looking for more avenues for adoption of the Qpid and Proton projects and AMQP as a standard.
for now, lets try and get these into the Plus repos then.
Okay, so what is my first step for this?
-
Darryl L. Pierce -
Karanbir Singh -
Karsten Wade -
Kay Williams -
Les Mikesell -
Matthew Miller