1:25 a.m.
Hallo all,
how EPEL will deal with so called software channels in RHN? E.g., RHEL4
has channel Red Hat Web Application Stack and it contains httpd-2.0.55
(which replaces standard httpd-2.0.52 from RHEL4) and
mysql-connector-odbc-3.51.12 (there is no such package in the standard
RHEL4 distribution). Will EPEL packages be built without replacing
packages only from standard distribution or also from additional software
channels and Red Hat products (such as RHCS, GFS, ...)?
--
Sincerely yours,
Andrey Klyachkin
UNIX Systems Administrator, RaiffeisenBank Austria, Moscow
This message and any attachment are confidential and may be privileged or otherwise
protected from disclosure. If you are not the intended recipient any use, distribution,
copying or disclosure is strictly prohibited. If you have received this message in error,
please notify the sender immediately either by telephone or by e-mail and delete this
message and any attachment from your system. Correspondence via e-mail is for information
purposes only. ZAO Raiffeisenbank Austria neither makes nor accepts legally binding
statements by e-mail unless otherwise agreed.
1:41 a.m.
Andrey KLYACHKIN wrote:
Hallo all,
how EPEL will deal with so called software channels in RHN? E.g., RHEL4
has channel Red Hat Web Application Stack and it contains httpd-2.0.55
(which replaces standard httpd-2.0.52 from RHEL4) and
mysql-connector-odbc-3.51.12 (there is no such package in the standard
RHEL4 distribution). Will EPEL packages be built without replacing
packages only from standard distribution or also from additional
software channels and Red Hat products (such as RHCS, GFS, ...)?
These are called layered products and they won't be replaced by EPEL
either. This is answered in the EPEL FAQ at
http://fedoraproject.org/wiki/EPEL/FAQ
Rahul
1:48 a.m.
On 02.08.2007 08:41, Rahul Sundaram wrote:
Andrey KLYACHKIN wrote:
> how EPEL will deal with so called software channels in RHN? E.g., RHEL4
> has channel Red Hat Web Application Stack and it contains httpd-2.0.55
> (which replaces standard httpd-2.0.52 from RHEL4) and
> mysql-connector-odbc-3.51.12 (there is no such package in the standard
> RHEL4 distribution). Will EPEL packages be built without replacing
> packages only from standard distribution or also from additional
> software channels and Red Hat products (such as RHCS, GFS, ...)?
These are called layered products and they won't be replaced by EPEL
either. This is answered in the EPEL FAQ at
http://fedoraproject.org/wiki/EPEL/FAQ
Just wondering: would it be fine for EPEL to ship for example
mysql-connector-odbc under a different name
("mysql-connector-odbc-epel")? Then we would not replace packages from
layered products, just provide something (without support) that's also
provided by a layered product (which has support).
I'd tend to answer my question from above with "yes".
CU
thl
3:08 a.m.
Thorsten Leemhuis wrote:
Just wondering: would it be fine for EPEL to ship for example
mysql-connector-odbc under a different name
("mysql-connector-odbc-epel")? Then we would not replace packages from
layered products, just provide something (without support) that's also
provided by a layered product (which has support).
That depends on how comfortable you are letting EPEL be a way to bypass
a product requirement essentially. If it is for libraries it might still
be required and useful for other reasons but what about say fedora
directory server in EPEL?
Rahul
3:33 a.m.
On 02.08.2007 10:08, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:
> Just wondering: would it be fine for EPEL to ship for example
> mysql-connector-odbc under a different name
> ("mysql-connector-odbc-epel")? Then we would not replace packages from
> layered products, just provide something (without support) that's also
> provided by a layered product (which has support).
That depends on how comfortable you are letting EPEL be a way to bypass
a product requirement essentially.
Complicated topic.
If it is for libraries it might still be required and useful for
other
reasons
Exactly. Not having some libs just because some layered product ships
them as well could be problematic for EPEL and hurt it a lot.
but what about say fedora directory server in EPEL?
I'm unsure myself about this one. A *short* version and just a fragment
of the thoughts in my head: people pay Red Hat for the support, but some
people might just want the support for the OS, but not for a specific
software they install. Should we try to force those people into the
existing model (users nevertheless can just rebuild the Fedora-DS or
RHEL-DS SRPM) or do we simply offer what we have and let them chose if
they want payed support or not?
CU
knurd
3:46 a.m.
Thorsten Leemhuis wrote:
On 02.08.2007 10:08, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
>
>
>> Just wondering: would it be fine for EPEL to ship for example
>> mysql-connector-odbc under a different name
>> ("mysql-connector-odbc-epel")? Then we would not replace packages from
>> layered products, just provide something (without support) that's also
>> provided by a layered product (which has support).
>>
> That depends on how comfortable you are letting EPEL be a way to bypass
> a product requirement essentially.
>
Complicated topic.
> If it is for libraries it might still be required and useful for other
> reasons
>
Exactly. Not having some libs just because some layered product ships
them as well could be problematic for EPEL and hurt it a lot.
> but what about say fedora directory server in EPEL?
>
I'm unsure myself about this one. A *short* version and just a fragment
of the thoughts in my head: people pay Red Hat for the support, but some
people might just want the support for the OS, but not for a specific
software they install. Should we try to force those people into the
existing model (users nevertheless can just rebuild the Fedora-DS or
RHEL-DS SRPM) or do we simply offer what we have and let them chose if
they want payed support or not?
How about using the yum protectbase plugin ? With
it, it would be
trivial to make sure we never replace core/layered/other important products
--
Manuel Wolfshant linux registered user #131416
IT manager NoBug Consulting SRL
http://www.brainbench.com/transcript.jsp?pid=40317
4:12 a.m.
Manuel Wolfshant wrote:
How about using the yum protectbase plugin ? With it, it would be
trivial to make sure we never replace core/layered/other important products
That wouldn't prevent machine X having subscribed to no software
channels at all installing EPEL foo(-epel).rpm and then subscribing to a
channel providing RHEL foo.rpm.
IMHO, EPEL should stick to what it does best: Extra Packages for
Enterprise Linux, not Extra Packages for Enterprise Linux and The
Software of Those Channels You Didn't Subscribe to With RH.
If anywhere along the path say foo needs a lib or dep that is not in
RHEL, imho, foo shouldn't be in EPEL either -regardless of how EPEL
/could/ make it work. Rather make an effort to get the lib or dep in the
next RHEL release.
Just my $0.02
Kind regards,
Jeroen van Meeuwen
-kanarip
3:56 a.m.
Thorsten Leemhuis wrote:
Exactly. Not having some libs just because some layered product ships
them as well could be problematic for EPEL and hurt it a lot.
In this talk to Daniel Riek and see if it feasible to add that library
to the base product. It won't happen immediately. New packages are added
only when required in the sync updates which was previously quarterly
and still somewhat follows that schedule.
Even then some customers consider the changes in between these updates
large and stick with a older version (ie) 4.2 though 4.4 has been
released and Red Hat has announced recently a separate support and
updates stream for that case so packages added in the later revisions
will be excluded for them. As you can imagine there is a lot of
complexity in managing all these but you can probably ignore this case
since customers using this update stream are highly sensitive to changes
and are unlikely to just pull in packages from any external source
without commercial support guarantees.
I'm unsure myself about this one. A *short* version and just a fragment
of the thoughts in my head: people pay Red Hat for the support, but some
people might just want the support for the OS, but not for a specific
software they install. Should we try to force those people into the
existing model (users nevertheless can just rebuild the Fedora-DS or
RHEL-DS SRPM) or do we simply offer what we have and let them chose if
they want payed support or not?
I am all in for providing more flexibility here but I don't really want
to create more support pains. Since the base product that we are
complimenting has support has one of the core values this has a high
priority.
Rahul
3:28 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thorsten Leemhuis wrote:
Just wondering: would it be fine for EPEL to ship for example
mysql-connector-odbc under a different name
("mysql-connector-odbc-epel")? Then we would not replace packages from
layered products, just provide something (without support) that's also
provided by a layered product (which has support).
Well it could become a support nightmare though at the worst case. What
would prevent the entropy from increasing is a nice definition of what
is "Extra Packages" when it comes to "Enterprise Linux" and what are
the
essential facts one should consider when going forward adding the EPEL
repository and adding the packages to a subscribed and supportable
Enterprise Linux system
I'd tend to answer my question from above with "yes".
- --
You see things; and you say 'Why?';
But I dream things that never were;
and I say 'Why not?' - George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGsZW5XQZpNTcrCzMRAm4sAJ0caU6+ph/TGJbovVagaCtY8JGxAgCfRRAR
vteQ+e6Z+AOa5ha8OWVaSZM=
=r5g9
-----END PGP SIGNATURE-----
3:42 a.m.
On 02.08.2007 10:28, Sankarshan Mukhopadhyay wrote:
Thorsten Leemhuis wrote:
> Just wondering: would it be fine for EPEL to ship for example
> mysql-connector-odbc under a different name
> ("mysql-connector-odbc-epel")? Then we would not replace packages from
> layered products, just provide something (without support) that's also
> provided by a layered product (which has support).
Well it could become a support nightmare though at the worst case.
Well, we'd need to make sure the different packages don't get installed
at the same time. But yeah, point taken.
*If* we ever should need a *library* in EPEL that's currently part of a
layered product then it might be the best for all parties involved to
ship that library in RHEL proper, and not in the layered product.
CU
thl
3:53 a.m.
On 02.08.2007 10:42, Thorsten Leemhuis wrote:
On 02.08.2007 10:28, Sankarshan Mukhopadhyay wrote:
> Thorsten Leemhuis wrote:
>
>> Just wondering: would it be fine for EPEL to ship for example
>> mysql-connector-odbc under a different name
>> ("mysql-connector-odbc-epel")? Then we would not replace packages from
>> layered products, just provide something (without support) that's also
>> provided by a layered product (which has support).
> Well it could become a support nightmare though at the worst case.
Well, we'd need to make sure the different packages don't get installed
at the same time. But yeah, point taken.
*If* we ever should need a *library* in EPEL that's currently part of a
layered product then it might be the best for all parties involved to
ship that library in RHEL proper, and not in the layered product.
In addition: maybe we should in fact discuss this further when this
"*if*" case actually shows up and then look out for a individual
solution together with Red Hat that serves both sides needs somehow.
CU
thl
9:42 p.m.
On Thu, 2 Aug 2007, Thorsten Leemhuis wrote:
Just wondering: would it be fine for EPEL to ship for example
mysql-connector-odbc under a different name
("mysql-connector-odbc-epel")?
and this form of 'at the end of the package name' marking
would be an improvement, compared to a repotag at the end of
release, just how?
It is just as unsightly, and just as much, if not worse,
namespace clutter, but worse, as it now would need to carry an
explicit (and manual, hence error-prone) spec file mungeing:
Provides: mysql-connector-odbc
entry for dependency resolution. Just wait until a versioned
Provides is needed which cannot be well expressed.
-- Russ Herrold
6105
days inactive
6106
days old
epel-devel@lists.fedoraproject.org
11 comments
7 participants
participants (7)
-
Andrey KLYACHKIN -
Jeroen van Meeuwen -
Manuel Wolfshant -
R P Herrold -
Rahul Sundaram -
Sankarshan Mukhopadhyay -
Thorsten Leemhuis