terminology question

rwv37

rwv37

I'm working on making a program to deal with ports (as a layer on top of ports-mgmt/synth to simplify my use of it). In the course of doing so, while creating class names, method names, etc., I've found that I don't really have satisfying and/or clear terminology for various concepts, so I'm wondering if there is official, standard-ish, and/or common terminology.

Consider both something that has flavors and something that does not; for example git and bash. Then the following distinct concepts exist in my mind, with each of the concepts described by giving it for both git and bash:
  1. "devel" and "shells".
  2. "git" and "bash".
  3. "default" and null (or empty or whatever).
  4. "devel/git" and "shells/bash".
  5. "devel/git@default" and "shells/bash".
  6. "git@default" and "bash".
So, #1 is obviously "category name". But I've come to realize that my mental terminology of the rest of them suffers from a lack of clear distinctions. For example, I think of #2, #4, #5, and maybe even #6 as "port name". And I think of #3, #5, and #6 as "flavor".

The six concepts are distinct and clear in my mind, but my names of the concepts are not. This is not a problem for me when I think about this stuff - it doesn't really matter that I think of both "default" and "git@default" as being "flavors" - but it does matter when it comes to naming the six concepts in code.

The things I've thought of to resolve this problem seem either unsatisfying in a potentially confusing way (e.g. #2 "port name" and #5 "full port name") or awfully verbose (e.g. #2 "port name" and #6 "category and port and flavor name".

This is obviously not the most important problem in the world - the "unsatisfying" or "verbose" solutions would in some sense be fine - but it has been gnawing at my brain for some time now nonetheless. So, I'm hoping for official, standard-ish, and/or common terminology.
 
1. There are categories, both physical (an actual directory exists in the ports tree) and virtual (no directory). A port can have one or multiple categories, the first being the primary category, which must be a physical one, the port's directory will be placed there.

2. These are (most likely) the port names. Or just the directory names, although in almost any case, this should be the same.

3. In your context, these are the flavors. Although there's no such thing as "null", most ports just don't have flavors. Also, there's always a default flavor, but it doesn't have to be named "default".

4. These are called "origins" ... the path inside the ports tree where the port resides.

5. origins with (explicit) flavor name.

6. I don't think such a thing exists ...

What you're missing is the package name. In many cases, this is just the same as the port name, but it doesn't have to be. In presence of flavors, each flavor must lead to its own package name (because a package is built for each flavor). There's no fixed rule for that, but quite often, the flavor name is just appended with a minus to the package name, e.g. building misc/foo@bar will result in a package named foo-bar.
 
Thanks, zirias@. "Origin" really helps. I don't think I have to worry about any category that's not a primary category, and I don't think I have to deal with #6 (was mostly just curious about that one), so I think these work for my purposes here:
  1. category
  2. port
  3. flavor
  4. origin
  5. flavored origin
  6. (not needed)

 
I think that OP could consider Poudriere for package compilation. When it comes to getting help with using Poudriere for package compilation, the Forums are a great place to get that help.

Poudriere is the official compilation tool used by the FreeBSD project, too. And it can be as simple or as complex as you choose. It does have pretty sensible defaults that OP can use for very simple but workable cases.

Writing your own stuff to go on top of the existing, official tools - that is actually an extra layer of complexity. If something goes wrong with your tool - is it your tool, is it incorrect options sent to the tool underneath (like misuse of say, category or flavor option, due to losing track), is it a problem with the specific package (I've had that happen to me), or is it something else altogether?

With your own stuff - you're kind of on your own for troubleshooting it, and getting the ducks in a row. But if OP is willing to live with that, and go try to pull it off anyway - that's for OP to decide. :)
 
The makefiles do have variable-names for the various components:

Code: 
security/py-pycryptodomex@py39:
  PKGNAMEPREFIX=py39-
  PORTNAME=pycryptodome
  PKGNAMESUFFIX=x
  MASTERDIR=/usr/ports/security/py-pycryptodomex/../py-pycryptodome

I wouldn't start writing such on my own today. When I did, there was no poudriere yet, and the dependency graphs were always wrong.
 
PMc said:
I wouldn't start writing such on my own today. When I did, there was no poudriere yet, and the dependency graphs were always wrong.
Click to expand...
The dependency graphs were incorrect in what way? With over 30,000 ports, and lots of dependencies to resolve, you kind of have to have rules for resolving dependencies so that you have an acyclic directed graph ... but there's always a chance to get carried away with dependency specs and create circular dependencies. I've had that happen to me a few times, I had to learn how to troubleshoot my way out of that.

That kind of creates a strategy for Poudriere - first, compile all the packages using just the Ports Collection, and specify dependencies for the first time. After that first round of compiling completes (you're happy with the packages, and compilation completes successfully) that's a good time to create a list of packages to feed to Poudriere... I just think that it may be a better idea to learn Poudriere than to try and reinvent the wheel.

grahamperrin said:
component: add SUBPACKAGES · freebsd/freebsd-ports@4756476

Relevant?
Click to expand...
I think that subpackages are an interesting idea, but there's already options in Makefiles to install stuff like documentation, compile a debug version, compile with testing/examples, etc. I personally have a love-hate relationship with the DOCS Makefile flag, because sometimes it just unzips/downloads HTML/PDF/roff documentation into /usr/doc/, and sometimes it invokes automatic documentation generator (which is a separate port that still needs to be compiled, along with dependencies, installed, and then executed). We do have metapackages, like x11/kde5 already... I'd personally vote against adding extra complexity by introducing the SUBPACKAGES tag...
 
Thank you for the concern, but the tool will just do things like take some config files saying "These are the ports I actually want" and transform them into a format that's appropriate to give to Synth.
 
For that kind of scenario, I prepared a list of ports to feed to Poudriere simply by using system-provided utilities, like sed/awk, sh, grep, and the like. Once I was happy with the list (correct format, culled from pkg info, THAT's when I decided it's time to feed it to Poudriere.

Basically, my point is, try to learn the standard utilities first, see how they fit together, and then automate the chores necessary to get the system to compile the stuff you want. Taking a shortcut to the end of the process and trying to correct things from there - that approach is not the most productive one... I got burned by that a few times before I learned.
 
astyle said:
For that kind of scenario, I prepared a list of ports to feed to Poudriere simply by using system-provided utilities, like sed/awk, sh, grep, and the like. Once I was happy with the list (correct format, culled from pkg info, THAT's when I decided it's time to feed it to Poudriere.
Click to expand...
Yes, I've done that, and have been using the scripts I've made for... years? Many months at least. In the course of using them, I have come to realize that I could make significant improvements to them. I am now doing so.
 
You must log in or register to reply here.
Back
Top