Re: Overeager cleaning of -devel provides
Jeff Johnson <[email protected]> Thu, 1 Aug 2013 20:55:49 -0400
| Newsgroups | gmane.linux.mandrake.cooker.devel |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-7806F2D1-899B-49D8-8CEF-A1EACCD33B97 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone On Aug 1, 2013, at 6:33 PM, Per =C3=98yvind Karlsen <[email protected]>= wrote: > 2013/8/1 Matthew Dawkins <[email protected]> >> I understand Multiarch quite well. > You obviously don't as you don't understand why one would install both 32 &= 64 bit builds of -devel packages simultanously.. You don't understand the KISS of how Fedora (and Red Hat) solved the same issue: All include files are identical on all architectures. Root cause for file conflicts solved by patching sources _ONCE_ and Fedora/RedHat has done all the heavy lifting. I dare you to suggest that I do not understand Mandriva's multi arch solutio= n. The net effect of Mandriva's stubborn insistence on failed schemes like m= ulti arch is vendor lock-in by making build recipes too different and too co= mplicated to change. >> What is apparent is that you don't understand the library packaging polic= y all to well. So, go ahead and have a read: >> http://wiki.mandriva.com/en/Libraries_policy >>=20 >> There's two sections that pertain to your misconception of package names a= nd provides that you particularly need to take note. >>=20 >> The actual naming however _IS_VERY_ important. It's why the library namin= g policy for Mandriva mimics that of Debian's. > We're talking about naming of provides, not naming of packages. > =20 There is a very simple solution that need not differentiate between provides= and names and require "canonical" definitions and the endless nit-picks: Don't do that! hth 73 de Jeff > -- > Regards, > Per =C3=98yvind --Apple-Mail-7806F2D1-899B-49D8-8CEF-A1EACCD33B97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div><br><br>Sent from my iPhone</div><div>= <br>On Aug 1, 2013, at 6:33 PM, Per =C3=98yvind Karlsen <<a href=3D"mailt= o:[email protected]">[email protected]</a>> wrote:<br><br></div= ><blockquote type=3D"cite"><div>2013/8/1 Matthew Dawkins <span dir=3D"ltr">&= lt;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a>></span><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= > <div dir=3D"ltr"><div><div>I understand Multiarch quite well.</div></div></d= iv></blockquote><div>You obviously don't as you don't understand why one wou= ld install both 32 & 64 bit builds of -devel packages simultanously..</d= iv></div></div></blockquote><div><br></div>You don't understand the KISS<div= >of how Fedora (and Red Hat)</div><div>solved the same issue:</div><div><br>= </div><div> All include files are identical on</div><div> = all architectures.</div><div><br></div><div>Root cause for fil= e conflicts solved by</div><div>patching sources _ONCE_ and Fedora/RedHat ha= s done all the heavy lifting.</div><div><br></div><div>I dare you to suggest= that I do not understand Mandriva's multi arch solution. The net effect of M= andriva's stubborn insistence on failed schemes like multi arch is vendor lo= ck-in by making build recipes too different and too complicated to change.</= div><div><br></div><div><blockquote type=3D"cite"><div><div class=3D"gmail_q= uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div> What is appa= rent is that you don't understand the library packaging policy all to well. S= o, go ahead and have a read:<br> <a href=3D"http://wiki.mandriva.com/en/Libraries_policy" target=3D"_blank">h= ttp://wiki.mandriva.com/en/Libraries_policy</a><br> <br></div>There's two sections that pertain to your misconception of package= names and provides that you particularly need to take note.<br><br></div><d= iv>The actual naming however _IS_VERY_ important. It's why the library namin= g policy for Mandriva mimics that of Debian's.<br> </div></div></blockquote><div>We're talking about naming of provides, not na= ming of packages.</div><div> </div></div></div></blockquote><div><br></= div>There is a very simple solution that need not differentiate between prov= ides and names and require "canonical" definitions and the endless nit-picks= :</div><div><br></div><div> Don't do that!</div><d= iv><br></div><div>hth</div><div><br></div><div>73 de Jeff<br><blockquote typ= e=3D"cite"><div><div class=3D"gmail_quote"><div>--</div><div>Regards,</div><= div>Per =C3=98yvind</div></div> </div></blockquote></div></body></html>= --Apple-Mail-7806F2D1-899B-49D8-8CEF-A1EACCD33B97--