FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 12-20-2010, 07:41 PM
Kevin Fenzi
 
Default Proposal on what packages can be in EPEL6

I'd like to put forth a proposal here, comments or other opinions very
welcome.

In EPEL4/5 we have a policy of: "EPEL won't ship anything that is in
the Advanced Platform set of packages". This is easy to check, as all
these have src.rpms on mirrors. This includes:

JBEAP
JBEWS
JBWFK
os
RHCERT
RHDirServ
RHDOCS
RHEIPA
RHEMRG
RHHC
RHNPROXY
RHNSAT
RHNTOOLS
RHUI
RHWAS
SJIS

(see:
http://mirrors.tummy.com/pub/ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en )

For EPEL6, we can't do this as their is no Advanced Platform, and the
secondary channels don't exist as src.rpms. We have:

6Server
6ComputeNode
6Client
6Workstation

and all the src.rpms in a single dir under those.

Additionally we have the following complications:

* Some packages only have binary rpms shipped for some arches. Ie, the
entire virt stack is x86_64. There's no client/workstation stuff in
ppc64. There's no java in ppc64.

* Some packages only have subpackages shipped in some arches (ie,
pacemaker-cts and pacemaker-docs are shipped in server-optional, but
the main pacemaker binary rpm is only in the HighAvailability
channel.

I would like to propose the following:

EPEL6 will not ship any packages that have src.rpms on public mirrors
under 6* directories with the following exception: If the binary rpm
is only shipped in some arches in RHEL, EPEL may ship that exact same
version (note that EPEL maintainer must keep up exactly with the RHEL
src.rpm).

So, this would leave us with:

* someone could maintain java in EPEL and build the exact src.rpm
version. If it took mods to work, I would say we should just not do
so and excludearch our java stuff.

* folks could push packages that are x86_64 only into epel, but should
keep them exactly the same as the rhel src.rpm.

* Items in other channels are fair game to ship in EPEL6.

Thoughts?

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 07:31 PM
Toshio Kuratomi
 
Default Proposal on what packages can be in EPEL6

On Mon, Dec 20, 2010 at 01:41:25PM -0700, Kevin Fenzi wrote:
> I'd like to put forth a proposal here, comments or other opinions very
> welcome.
>
> In EPEL4/5 we have a policy of: "EPEL won't ship anything that is in
> the Advanced Platform set of packages". This is easy to check, as all
> these have src.rpms on mirrors. This includes:
>
> JBEAP
> JBEWS
> JBWFK
> os
> RHCERT
> RHDirServ
> RHDOCS
> RHEIPA
> RHEMRG
> RHHC
> RHNPROXY
> RHNSAT
> RHNTOOLS
> RHUI
> RHWAS
> SJIS
>
> (see:
> http://mirrors.tummy.com/pub/ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en )
>
> For EPEL6, we can't do this as their is no Advanced Platform, and the
> secondary channels don't exist as src.rpms. We have:
>
> 6Server
> 6ComputeNode
> 6Client
> 6Workstation
>
> and all the src.rpms in a single dir under those.
>
> Additionally we have the following complications:
>
> * Some packages only have binary rpms shipped for some arches. Ie, the
> entire virt stack is x86_64. There's no client/workstation stuff in
> ppc64. There's no java in ppc64.
>
> * Some packages only have subpackages shipped in some arches (ie,
> pacemaker-cts and pacemaker-docs are shipped in server-optional, but
> the main pacemaker binary rpm is only in the HighAvailability
> channel.
>
> I would like to propose the following:
>
> EPEL6 will not ship any packages that have src.rpms on public mirrors
> under 6* directories with the following exception: If the binary rpm
> is only shipped in some arches in RHEL, EPEL may ship that exact same
> version (note that EPEL maintainer must keep up exactly with the RHEL
> src.rpm).
>
> So, this would leave us with:
>
> * someone could maintain java in EPEL and build the exact src.rpm
> version. If it took mods to work, I would say we should just not do
> so and excludearch our java stuff.
>
> * folks could push packages that are x86_64 only into epel, but should
> keep them exactly the same as the rhel src.rpm.
>
> * Items in other channels are fair game to ship in EPEL6.
>
> Thoughts?
>
I don't 100% like this but it seems like the best we can do with a messy
situation. The only thought I have is we might want to modify some of this
after we see what CentOS does. For instance, if they ship the virt stack on
x86 but do have to make modifications to make it work there we should
consider rebuilding with their packages or rebuilding with packages that
are NEVR lower than the RHEL packages but include the CentOS changes.

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 07:32 PM
Orion Poplawski
 
Default Proposal on what packages can be in EPEL6

On 12/20/2010 01:41 PM, Kevin Fenzi wrote:

I'd like to put forth a proposal here, comments or other opinions very
welcome.




Additionally we have the following complications:

* Some packages only have binary rpms shipped for some arches. Ie, the
entire virt stack is x86_64. There's no client/workstation stuff in
ppc64. There's no java in ppc64.

* Some packages only have subpackages shipped in some arches (ie,
pacemaker-cts and pacemaker-docs are shipped in server-optional, but
the main pacemaker binary rpm is only in the HighAvailability
channel.

I would like to propose the following:

EPEL6 will not ship any packages that have src.rpms on public mirrors
under 6* directories with the following exception: If the binary rpm
is only shipped in some arches in RHEL, EPEL may ship that exact same
version (note that EPEL maintainer must keep up exactly with the RHEL
src.rpm).

So, this would leave us with:

* someone could maintain java in EPEL and build the exact src.rpm
version. If it took mods to work, I would say we should just not do
so and excludearch our java stuff.

* folks could push packages that are x86_64 only into epel, but should
keep them exactly the same as the rhel src.rpm.


Using ExclusiveArch or ExcludeArch? Or just let them be in multiple repos
assuming that they will really and truly be the same?



* Items in other channels are fair game to ship in EPEL6.

Thoughts?

kevin


Fine by me. My concern at the moment is a multilib issue - gcc-gfortran.i686
not being present in the x86_64 repository, which causes:


Broken deps for x86_64
----------------------------------------------------------
getdata-devel-0.6.2-1.el6.i686 requires gcc-gfortran(x86-32)

Other than dropping the %{_isa} from the Requires, not sure there is anything
else we can do. But I haven't seen much comment on it though


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 09:32 PM
Kevin Fenzi
 
Default Proposal on what packages can be in EPEL6

On Tue, 21 Dec 2010 12:31:30 -0800
Toshio Kuratomi <a.badger@gmail.com> wrote:

> I don't 100% like this but it seems like the best we can do with a
> messy situation. The only thought I have is we might want to modify
> some of this after we see what CentOS does. For instance, if they
> ship the virt stack on x86 but do have to make modifications to make
> it work there we should consider rebuilding with their packages or
> rebuilding with packages that are NEVR lower than the RHEL packages
> but include the CentOS changes.

Yeah, sounds reasonable to me.

On Tue, 21 Dec 2010 13:32:58 -0700
Orion Poplawski <orion@cora.nwra.com> wrote:

> Using ExclusiveArch or ExcludeArch? Or just let them be in multiple
> repos assuming that they will really and truly be the same?

Well, there's downsides to either. I guess just adding a ExclusiveArch
isn't too much change, but it is change. Would it be bad just just
import and rebuild them exactly from the src.rpm?

We should spell out what we want here exactly for sure.

> Fine by me. My concern at the moment is a multilib issue -
> gcc-gfortran.i686 not being present in the x86_64 repository, which
> causes:
>
> Broken deps for x86_64
> ----------------------------------------------------------
> getdata-devel-0.6.2-1.el6.i686 requires gcc-gfortran(x86-32)
>
> Other than dropping the %{_isa} from the Requires, not sure there is
> anything else we can do. But I haven't seen much comment on it though

I don't see any other solution. We can't change the way RHEL composes
their trees. I suppose you could file a bug and ask them to ship the
32bit one in the 64bit tree, but I am pretty sure they will just say
no.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 09:57 PM
Kevin Fenzi
 
Default Proposal on what packages can be in EPEL6

On Tue, 21 Dec 2010 15:32:04 -0700
Kevin Fenzi <kevin@scrye.com> wrote:

...snip...

> Well, there's downsides to either. I guess just adding a ExclusiveArch
> isn't too much change, but it is change. Would it be bad just just
> import and rebuild them exactly from the src.rpm?
>
> We should spell out what we want here exactly for sure.

Replying to myself here. Obviously we do have to modify them because
the rhel ones have either Exclusivearch or Excludearch anyhow.

So, I think it would make sense to require adding:

ExclusiveArch: ppc64

to any rhel src.rpms that we rebuild for epel.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 10:03 PM
Dennis Gilmore
 
Default Proposal on what packages can be in EPEL6

On Tuesday, December 21, 2010 04:57:53 pm Kevin Fenzi wrote:
> On Tue, 21 Dec 2010 15:32:04 -0700
> Kevin Fenzi <kevin@scrye.com> wrote:
>
> ...snip...
>
> > Well, there's downsides to either. I guess just adding a ExclusiveArch
> > isn't too much change, but it is change. Would it be bad just just
> > import and rebuild them exactly from the src.rpm?
> >
> > We should spell out what we want here exactly for sure.
>
> Replying to myself here. Obviously we do have to modify them because
> the rhel ones have either Exclusivearch or Excludearch anyhow.
>
> So, I think it would make sense to require adding:
>
> ExclusiveArch: ppc64
>
> to any rhel src.rpms that we rebuild for epel.
>
> kevin
We cant do that, because of the way koji works we would end up with only the
ppc64 version available to build against, we build and ship it on all arches
or none.

Dennis
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 10:08 PM
Kevin Fenzi
 
Default Proposal on what packages can be in EPEL6

On Tue, 21 Dec 2010 17:03:08 -0600
Dennis Gilmore <dennis@ausil.us> wrote:

> We cant do that, because of the way koji works we would end up with
> only the ppc64 version available to build against, we build and ship
> it on all arches or none.

Ah right.

ok. That settles that.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2010, 10:09 PM
Stephen John Smoogen
 
Default Proposal on what packages can be in EPEL6

On Tue, Dec 21, 2010 at 13:32, Orion Poplawski <orion@cora.nwra.com> wrote:
> On 12/20/2010 01:41 PM, Kevin Fenzi wrote:
>>
>> I'd like to put forth a proposal here, comments or other opinions very
>> welcome.

Question... who is using ppc64 on here to test/fix/help? From the
sounds of it, openjdk is going to take a bunch of bootstrapping of
building it from F12 rpms a couple of rounds until you have something
'working' on El6.

Does anyone have a need for it? [EG does IBM have some poor bas^W
developer who can help us through this?]

--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-22-2010, 07:02 AM
Dan Horák
 
Default Proposal on what packages can be in EPEL6

Stephen John Smoogen p*še v Út 21. 12. 2010 v 16:09 -0700:
> On Tue, Dec 21, 2010 at 13:32, Orion Poplawski <orion@cora.nwra.com> wrote:
> > On 12/20/2010 01:41 PM, Kevin Fenzi wrote:
> >>
> >> I'd like to put forth a proposal here, comments or other opinions very
> >> welcome.
>
> Question... who is using ppc64 on here to test/fix/help? From the
> sounds of it, openjdk is going to take a bunch of bootstrapping of
> building it from F12 rpms a couple of rounds until you have something
> 'working' on El6.

What about to import an older EL-6 build
(java-1.6.0-openjdk-1.6.0.0-1.17.b16.el6 is built for all arches) into
koji and then use it to build the latest one? We did that in
Fedora/s390x.


Dan


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 10:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org