<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Sept 2023 at 08:45, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 21 set 2023 alle ore 16:38 Eric Curtin <<a href="mailto:ecurtin@redhat.com" target="_blank">ecurtin@redhat.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Another similar technique that's also helpful, is if we ask the Fedora<br>
maintainer to create an EPEL9 version of the package, that way the<br>
community can help maintain the package and you can just "mirror" EPEL<br>
(assuming you keep an eye on the changes they make).<br>
<br>
I did this recently when I asked the erofs-utils maintainer to create<br>
an EPEL9 rpm for our erosfs related features we are working on:<br>
<br>
<a href="https://src.fedoraproject.org/rpms/erofs-utils" rel="noreferrer" target="_blank">https://src.fedoraproject.org/rpms/erofs-utils</a><br></blockquote></div><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">I'm not sure this is a good idea.</span></div><div><span class="gmail_signature_prefix">According to <a href="https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it" target="_blank">https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it</a></span></div><div><span class="gmail_signature_prefix">```</span></div><div><span class="gmail_signature_prefix">EPEL is a selection of packages from Fedora, but only packages that are not in RHEL or its layered products to avoid conflicts.<br></span></div><div><span class="gmail_signature_prefix">```</span></div><div><span class="gmail_signature_prefix"><br></span></div></span></div></blockquote><div><br></div><div>So this isn't 'correct'. EPEL is a selection of packages from Fedora, but only packages that are not in RHEL to avoid conflicts. </div><div><br></div><div>EPEL will ship things which are in layered products usually because the layered product is tired of getting requests for supporting libZZZ in RHEL when they don't want to but they know that a lot of people are needing it. [Or as some layered products have said the version they have is only there for 1 limited reason but they can't update it so no one should use that version.]</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix"></span></div><div><span class="gmail_signature_prefix">And RHIVOS is a layered product so having stuff in EPEL may end up with conflicts later on.</span></div><div><span class="gmail_signature_prefix">We had similar issues with <a href="https://koji.fedoraproject.org/koji/packageinfo?packageID=12742" target="_blank">mom</a> and <a href="https://koji.fedoraproject.org/koji/packageinfo?packageID=12944" target="_blank">vdsm</a> packages which were also shipped in Red Hat Virtualization (downstream of oVirt project) in the past and we had to drop them from EPEL to solve issues.</span></div></span></div></blockquote><div><br></div><div>I don't remember those specific packages being a problem on the EPEL side or what release that happened in. Most of the time we have dropped RHEL layered packages from EPEL because they got included in RHEL proper, or the packager was treating EPEL like Fedora with major unannounced updates every couple of weeks because the upstream was too active for enterprise.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix">I would rather avoid AutoSD collisions with EPEL if possible.</span></div><div><span class="gmail_signature_prefix"><br></span></div></span></div></blockquote><div><br></div><div>So up until now, the way I thought we have been getting things into AutoSD was:</div><div>0. Get it into a COPR</div><div>1. Get it in Fedora (so it could get an initial review and items)</div><div>2. Get it in EPEL (so it could be seen to work with RHEL and such)</div><div>3. Get it in Automotive SIG CBS (to work with CentOS Stream) to see if needed.</div><div>4. Get it into AutoSD if really needed. </div><div><br></div><div>Steps 3 and 4 have been generally harder than 0, 1 and 2. Plus a fair amount of stuff that has been 'requested' by partners eventually turns out not to be really wanted enough for us to take on the support burden. </div><div><br></div><div>I feel that most of the 'hard part' of getting things into 3 and 4 have been that we had a 'hole' in our policies around 'who owns this', 'what does it mean to own it', 'how do we properly review it', and a ton of other things. I believe this is what we are trying to formulate now?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix"></span></div>-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px"><span>Sandro</span> <span>Bonazzola</span><span style="text-transform:uppercase;color:rgb(170,170,170);margin:0px"></span></p><p style="margin:0px"><span style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:12px">MANAGER, SOFTWARE ENGINEERING</span></p><p style="margin:0px"><font color="#000000" face="RedHatText, sans-serif"><span style="font-size:12px">Red Hat In-Vehicle Operating System</span></font></p><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;margin:0px 0px 4px;font-size:12px"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat <span>EMEA</span></a></p><div style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:medium;margin-top:12px"><div style="margin-top:12px"><table border="0"><tbody><tr><td width="100px"><a href="https://www.redhat.com/" target="_blank"><img src="https://static.redhat.com/libs/redhat/brand-assets/2/corp/logo--200.png" width="96" height="23"></a></td><td style="font-size:12px"><div></div></td></tr></tbody></table></div></div><table border="0"><tbody><tr></tr></tbody></table><div style="margin-top:12px"><font color="#000000" face="arial, sans-serif" size="1"><b></b></font></div><div style="margin-top:12px"><font color="#000000" face="arial, sans-serif" size="1"><b>Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.<br></b></font></div><div style="margin-top:12px"><font color="#000000" face="arial, sans-serif" size="1"><b><br><br></b></font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
CentOS-automotive-sig mailing list<br>
<a href="mailto:CentOS-automotive-sig@centos.org" target="_blank">CentOS-automotive-sig@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-automotive-sig" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-automotive-sig</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div></div>Stephen Smoogen, Red Hat Automotive<br></div>Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren<br></div></div></div>