Date: Thu, 30 Dec 2021 18:13:41 -1000 From: "parv/freebsd" <parv.0zero9+freebsd@gmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Package naming conventions (?) Message-ID: <CABObuOpNsa5E-tyitObzingGn9xfvAvcGO3CwcLVz1k7OfD-5g@mail.gmail.com> In-Reply-To: <CABObuOpcsG=hgLTTqm-Pw9PMWrS__5uLohY4JWwJvq9O-G1fJA@mail.gmail.com> References: <34017.1640919003@segfault.tristatelogic.com> <CABObuOpcsG=hgLTTqm-Pw9PMWrS__5uLohY4JWwJvq9O-G1fJA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000004882b605d4696aa8 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 30, 2021 at 6:03 PM parv/freebsd wrote: > On Thu, Dec 30, 2021 at 4:51 PM Ronald F. Guilmette wrote: > >> I don't know if I should file a bug report on this or not. Feedback would >> be appreciated. >> >> There is a small problem with what appears to be the "standard" naming >> convention(s) for package names. > > ... > > You mean a *de facto*, not a written policy, on the '"standard"' > convention, > which is borne out to of package versions just happen to follow a pattern, > until now.? > ... Some "official" blurb on "version" ... https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-naming - parv -- --0000000000004882b605d4696aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace">On Thu, Dec 30, 2021 at 6:03 PM parv/freebsd wrote:<br>= </div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-family:m= onospace">On Thu, Dec 30, 2021 at 4:51 PM Ronald F. Guilmette wrote:<br></d= iv></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">I don't know if I should file a bug report on this or not.= =C2=A0 Feedback would<br> be appreciated.<br> <br> There is a small problem with what appears to be the "standard" n= aming<br> convention(s) for package names.</blockquote><div><span class=3D"gmail_defa= ult" style=3D"font-family:monospace">...</span>=C2=A0</div><div><br></div><= div><div style=3D"font-family:monospace">You mean a *de facto*, not a writt= en policy, on the '"standard"' convention,</div><div styl= e=3D"font-family:monospace">which is borne out to of package versions just = happen to follow a pattern,</div><div style=3D"font-family:monospace">until= now.?<br></div></div></div></div></blockquote><div><span class=3D"gmail_de= fault" style=3D"font-family:monospace">...</span></div><div><span class=3D"= gmail_default" style=3D"font-family:monospace"><br></span></div><div><span = class=3D"gmail_default" style=3D"font-family:monospace">Some "official= " blurb on "version"</span>=C2=A0<span class=3D"gmail_defaul= t" style=3D"font-family:monospace">...</span></div><div><span class=3D"gmai= l_default" style=3D"font-family:monospace"><br></span></div><div><span clas= s=3D"gmail_default" style=3D"font-family:monospace">=C2=A0 <a href=3D"https= ://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-naming">h= ttps://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-namin= g</a></span></div><div><span class=3D"gmail_default" style=3D"font-family:m= onospace"><br></span></div><div><span class=3D"gmail_default" style=3D"font= -family:monospace"><br></span></div><div><span class=3D"gmail_default" styl= e=3D"font-family:monospace">- parv</span></div><div><span class=3D"gmail_de= fault" style=3D"font-family:monospace"></span></div><div><span class=3D"gma= il_default" style=3D"font-family:monospace">-- <br></span></div><div><span = class=3D"gmail_default" style=3D"font-family:monospace"><br></span></div></= div></div> --0000000000004882b605d4696aa8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABObuOpNsa5E-tyitObzingGn9xfvAvcGO3CwcLVz1k7OfD-5g>