On Monday December 28 2015 00:46:51 Clemens Lang wrote: > This isn't redundant information,
Not for the port indexing system maybe, but for everything >> If you agree with this that might actually make looking at improving >> the index a bit more appealing to me :) > >I'm not sure whether I like relaxing the rule of naming a directory the >same as the port it provides, because that decision enforces structure >in our ports tree. If we remove that requirement, port names become >arbitrary. No, port DIR names become arbitrary. From what I understand the only reason they are not supposed to be arbitrary right now is because of the portdir name = port name assumption that is currently still required to avoid reindexing. There is no other side-effect of using a deviant portdir that I've been able to observe. If you ask me, the choice not to include the parent directory (and the category) in the indexing feature is just as arbitrary, yet lint does complain about a main category/dirname mismatch IIRC. And what's wrong with arbitrary portdir names as long as there is a minimum of common sense in their naming? I don't think anyone would chose a truly arbitrary and non-informative name for the directory in which they store their port files. It is true that for the vast majority of users, the portdir name is without any interest, maybe even for most port developers/maintainers. On the other hand, for those of the latter who maintain/develop lots of ports, there is an advantage in being able to organise the port tree the way that works best for them (= most efficiently). Take port:kde-extra-cmake-modules. The port was called that way mostly to make its nature clear to those who find it gets pulled in when installing something, and to avoid naming conflicts with potential other ports that install extra modules for cmake. KDE (build) code refers to it as ECM, however, so `kde/ECM` works much better when you have to refer to its port implementation from time to time than `kde/kde-extra-cmake-modules` . Similarly, if you maintain a growing but already large number of ports for KF5 packages, you can get around in the port tree much more easily if all those port directories do not all have a name that starts the same. Be it if you work with an IDE like I do (and thus have the limited width of the filesystem tree navigator to deal with) , through a Finder window or even with completion in a terminal, all information that is redundant (to the "user", because already available elsewhere) and repeated adds an additional attentional load. Compare kf5-attica kf5-baloo kf5-breeze kf5-breeze-icons kf5-cli-tools kf5-frameworkintegration kf5-gpgmepp kf5-kactivities kf5-kapidox kf5-karchive kf5-kate kf5-kauth kf5-kbookmarks kf5-kcmutils kf5-kcodecs kf5-kcompletion kf5-kconfig kf5-kconfigwidgets kf5-kcoreaddons kf5-kcrash kf5-kdbusaddons kf5-kdeclarative kf5-kdecoration kf5-kded kf5-kdelibs4support kf5-kdesignerplugin kf5-kdesu kf5-kdewebkit kf5-kdnssd kf5-kdoctools kf5-kemoticons kf5-kfilemetadata kf5-kglobalaccel kf5-kguiaddons kf5-khtml kf5-ki18n kf5-kiconthemes kf5-kidletime kf5-kimageformats kf5-kinit kf5-kio kf5-kitemmodels kf5-kitemviews kf5-kjobwidgets kf5-kjs kf5-knewstuff kf5-knotifications kf5-knotifyconfig kf5-kompare kf5-kpackage kf5-kparts kf5-kpeople kf5-kplotting kf5-kpty kf5-krunner kf5-kservice kf5-ktexteditor kf5-ktextwidgets kf5-kunitconversion kf5-kwallet kf5-kwalletmanager kf5-kwidgetsaddons kf5-kwindowsystem kf5-kxmlgui kf5-kxmlrpcclient kf5-libkomparediff2 kf5-oxygen kf5-oxygen-icons kf5-plasma-framew ork kf5-plasma-sdk kf5-solid kf5-sonnet kf5-systemsettings kf5-threadweaver with attica baloo breeze breeze-icons cli-tools frameworkintegration gpgmepp kactivities kapidox karchive kate kauth kbookmarks kcmutils kcodecs kcompletion kconfig kconfigwidgets kcoreaddons kcrash kdbusaddons kdeclarative kdecoration kded kdelibs4support kdesignerplugin kdesu kdewebkit kdnssd kdoctools kemoticons kfilemetadata kglobalaccel kguiaddons khtml ki18n kiconthemes kidletime kimageformats kinit kio kitemmodels kitemviews kjobwidgets kjs knewstuff knotifications knotifyconfig kompare kpackage kparts kpeople kplotting kpty krunner kservice ktexteditor ktextwidgets kunitconversion kwallet kwalletmanager kwidgetsaddons kwindowsystem kxmlgui kxmlrpcclient libkomparediff2 oxygen oxygen-icons plasma-framework plasma-sdk solid sonnet systemsettings threadweaver not hard to see in which one it's easier to select just about any target, right? It would be a bit different if it were usual to use a suffix (foo-kf5) rather than a prefix (kf5-foo). I've also considered developing on what could have been a numbering scheme (port:kdelibs4 -> port:kdelibs5) but that isn't natural because it wouldn't correspond to the naming of what is being installed (and there is no such thing as kdelibs in KF5). _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
