From nobody Fri Jul 28 20:31:19 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RCK6w59YQz4q7gt for ; Fri, 28 Jul 2023 20:31:51 +0000 (UTC) (envelope-from nsd@nantahala.systems) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RCK6t5GtTz3xKw; Fri, 28 Jul 2023 20:31:50 +0000 (UTC) (envelope-from nsd@nantahala.systems) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nantahala.systems header.s=fm1 header.b=iBOMLF4+; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=GkDzO6yF; spf=pass (mx1.freebsd.org: domain of nsd@nantahala.systems designates 64.147.123.27 as permitted sender) smtp.mailfrom=nsd@nantahala.systems; dmarc=none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id EFE8A2B00090; Fri, 28 Jul 2023 16:31:47 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute4.internal (MEProxy); Fri, 28 Jul 2023 16:31:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= nantahala.systems; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1690576307; x=1690583507; bh=JsxuBC8jmUYTNZMQG+o3VjTEOEEnSwlrhNt xk673eXc=; b=iBOMLF4+11NT84VGk9Y6Npw0Nt2l3RWm0NQsxtQaBDKiBUceka4 XLg3aO+dRP4ZFUBYrmDGS9JnmTuu4GwuWVvgQpAUxuMItvmBORoIX9P6QEsgKnzV vg7x3WvpddEOGzhiTJg6OmEzJmqrkxKU7+9sR9b/RaLV4nh0Zc1tvmzfHbBz05IE RbHpWGIMwL1cev9isxiWrHYZzZE6v05yP8+j+g1f4qmVzQHhsxTYyiPBQUx+k0hH N9mDepTVbZYW0eESZHZyJlks7RuEHaCXqjjQFRdwR227sLH7pGfP7++e39Axz53n I89giEjF5lFtXbyXOayVYqxAcAVjFAAiMZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1690576307; x=1690583507; bh=JsxuBC8jmUYTN ZMQG+o3VjTEOEEnSwlrhNtxk673eXc=; b=GkDzO6yFgW+Py5VSJFpcpBBPK/05D hZUppI1n2ZSwToTLdbmUHTczSRHKOUvzrVZK53bQOLLaJiwPdKxhgblELBVtya2c QxHOt4QL5t7Mu1jMqJZW+0HXWrZchyg5EEp37g4cIOHs4TaZZmwAMDl7OYvNDNb6 v9mp+vgN8TviL8Ha2t9nIjilukT6n5tP9/VFu5c/2qskzW3Js+Znb1BG2NbhQlV5 HZ61C8QSYAUJoi1yk2QxYF+EyHSYLTomPTrzMkjgD5LWP6e2fe57zMpdqA3/7B8G iHODEnnZ3CMW2tRpqXz2BzqdXb7pAKPcoxx4rZsHoloxfSqLk66CryTcg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrieeigddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhprghmtehlihgrshdqohhuthculdehtddtmdenucfjughrpefofgggkfgjfhffhffv vefutgesrgdtreerreerjeenucfhrhhomheppffuffcuoehnshgusehnrghnthgrhhgrlh grrdhshihsthgvmhhsqeenucggtffrrghtthgvrhhnpeeiiedtieetgeektdfhvdehhffg tdekffehfeffjefgheeujeejtedtfeehjeeivdenucffohhmrghinhepfhhrvggvsghsug drohhrghenucfuphgrmhetlhhirghspefpufffnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepnhhsugesnhgrnhhtrghhrghlrgdrshihshhtvg hmsh X-ME-Proxy: Feedback-ID: i73314619:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2DB2E234007E; Fri, 28 Jul 2023 16:31:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-592-ga9d4a09b4b-fm-defalarms-20230725.001-ga9d4a09b List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Message-Id: <71c92d25-a02b-40b4-9ef6-0d78c7f4fe73@app.fastmail.com> In-Reply-To: References: <6f2e2ce5-e1e8-437f-9e20-5fec3f6a305b@app.fastmail.com> Date: Sat, 29 Jul 2023 05:31:19 +0900 From: NSD To: "Jan Beich" Cc: freebsd-ports@freebsd.org Subject: Re: Reorganizing FreeBSD Ports Directory Structure for Non-X Window Managers and Wayland Support Content-Type: multipart/alternative; boundary=abdfed0966024fbdbe5edb33fa979d4a X-Spamd-Result: default: False [-4.07 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.27]; R_DKIM_ALLOW(-0.20)[nantahala.systems:s=fm1,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.27:from]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[nantahala.systems]; DKIM_TRACE(0.00)[nantahala.systems:+,messagingengine.com:+]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4RCK6t5GtTz3xKw X-Spamd-Bar: ---- --abdfed0966024fbdbe5edb33fa979d4a Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for sharing your feedback and concerns regarding the proposed = changes to the FreeBSD Port directories. I appreciate your input, and it= 's crucial to consider all perspectives before making any modifications. I understand that the Porter's Handbook recommends against adding new ph= ysical categories, and this is a valid point. We must carefully consider= the challenges associated with introducing new categories, ensuring con= sistency, and avoiding confusion. You mentioned that certain Wayland compositors also function as X11 wind= ow managers, like plasma5-kwin, kwinft, mutter, and enlightenment. This = highlights the complexity of categorization. Indeed, accommodating both = X11 and Wayland managers within separate directories might not be straig= htforward and could lead to complications. I recognize the importance of keeping the directory structure intuitive = and user-friendly to adhere to the Principle of Least Astonishment (POLA= ). Nested physical categories could potentially cause confusion and disr= upt existing workflows, which is something we should avoid. You suggested an alternative approach, advocating for tagging through vi= rtual categories, which offers more flexibility and discoverability. I f= ind the examples from Gentoo with "gui-wm" and PkgSrc with "wm" categori= es interesting, as they encompass both X11 window managers and Wayland c= ompositors. I completely understand your point about the challenge of finding the co= rrect category for ports, even for non-Wayland ones. The primary goal of= any directory reorganization should be to simplify the process and make= it more intuitive for users. Given your reservations and the complexities involved, I encourage furth= er discussions to find a solution that meets the needs of the community = while minimizing potential disruptions. Thank you once again for sharing your thoughts on this matter. Kind Regards, NSD On Thu, Jul 27, 2023, at 5:21 AM, Jan Beich wrote: > NSD writes: >=20 > > Dear All, > > > > FreeBSD could benefit from reorganizing its directory structure to > > accommodate non-X Window managers more effectively. Currently, these > > managers are all placed under the "x11" directories, which may not > > accurately represent their nature. >=20 > - Porter's Handbook recommends against[1] adding new physical categori= es > - Some Wayland compositors are also X11 window managers: plasma5-kwin, > kwinft, mutter and, probably, enlightment >=20 > [1] https://docs.freebsd.org/en/books/porters-handbook/makefiles/#prop= osing-categories >=20 > > A more intuitive approach could be to introduce a new "display" dire= ctory that encompasses various display managers. Here's a proposed reorg= anization: > > > > display/ > > =E2=94=9C=E2=94=80 x11/ > > =E2=94=82 =E2=94=94=E2=94=80... > > =E2=94=82 > > =E2=94=9C=E2=94=80 wayland/ > > =E2=94=82 =E2=94=9C=E2=94=80 wayland-wm/ > > =E2=94=82 =E2=94=94=E2=94=80 ... > > =E2=94=82 > > =E2=94=94=E2=94=80 arcan/ > > =E2=94=94=E2=94=80 arcan-wm/ > > =E2=94=94=E2=94=80 durden/ >=20 > - Nested physical categories are a POLA violation (going to confuse an= d break lots of stuff) > - Tagging is more flexible and discoverable and is already done via vi= rtual categories > - Gentoo uses "gui-wm" while PkgSrc uses "wm" for both X11 window mana= gers > and Wayland compositors; for example, x11* can be renamed to gui* >=20 > Anyway, I'm not interested. I already struggle to find the correct > category even for non-Wayland ports. >=20 --abdfed0966024fbdbe5edb33fa979d4a Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thank you for sha= ring your feedback and concerns regarding the proposed changes to the Fr= eeBSD Port directories. I appreciate your input, and it's crucial to con= sider all perspectives before making any modifications.

I unde= rstand that the Porter's Handbook recommends against adding new physical= categories, and this is a valid point. We must carefully consider the c= hallenges associated with introducing new categories, ensuring consisten= cy, and avoiding confusion.

You mentioned that certain Wayland= compositors also function as X11 window managers, like plasma5-kwin, kw= inft, mutter, and enlightenment. This highlights the complexity of categ= orization. Indeed, accommodating both X11 and Wayland managers within se= parate directories might not be straightforward and could lead to compli= cations.

I recognize the importance of keeping the directory s= tructure intuitive and user-friendly to adhere to the Principle of Least= Astonishment (POLA). Nested physical categories could potentially cause= confusion and disrupt existing workflows, which is something we should = avoid.

You suggested an alternative approach, advocating for t= agging through virtual categories, which offers more flexibility and dis= coverability. I find the examples from Gentoo with "gui-wm" and PkgSrc w= ith "wm" categories interesting, as they encompass both X11 window manag= ers and Wayland compositors.

I completely understand your poin= t about the challenge of finding the correct category for ports, even fo= r non-Wayland ones. The primary goal of any directory reorganization sho= uld be to simplify the process and make it more intuitive for users.
=

Given your reservations and the complexities involved, I encourag= e further discussions to find a solution that meets the needs of the com= munity while minimizing potential disruptions.

Thank you once = again for sharing your thoughts on this matter.

Kind Regards,
= NSD


On Thu, Jul 27, 2023, at 5:21 AM, Jan Bei= ch wrote:


- Some Wayland compositors are also X11 window managers: plasma5-kwin= ,
  kwinft, mutter and, probably, enlightment


> A more intuitive approach could be to int= roduce a new "display" directory that encompasses various display manage= rs. Here's a proposed reorganization:
>
&= gt; display/
>   =E2=94=9C=E2=94=80 x11/
<= /div>
>   =E2=94=82   =E2=94=94=E2=94=80...
>   =E2=94=82
>   =E2= =94=9C=E2=94=80 wayland/
>   =E2=94=82 &= nbsp; =E2=94=9C=E2=94=80 wayland-wm/
>   =E2=94= =82   =E2=94=94=E2=94=80 ...
>   =E2= =94=82
>   =E2=94=94=E2=94=80 arcan/
>       =E2=94=94=E2=94=80 arcan-= wm/
>        &n= bsp;  =E2=94=94=E2=94=80 durden/

- Nes= ted physical categories are a POLA violation (going to confuse and break= lots of stuff)
- Tagging is more flexible and discoverabl= e and is already done via virtual categories
- Gentoo uses= "gui-wm" while PkgSrc uses "wm" for both X11 window managers
<= div>  and Wayland compositors; for example, x11* can be renamed to = gui*

Anyway, I'm not interested. I already = struggle to find the correct
category even for non-Wayland= ports.


--abdfed0966024fbdbe5edb33fa979d4a--