ungleich-public/cdist
ungleich-public/cdist
7
4
Fork 10
Code Issues 58 Pull requests 15 Projects Releases Wiki Activity

lets try to agree which operating systems we support #95

New issue
Closed
opened 2021-11-20 13:23:49 +00:00 by ungleich-gitea · 7 comments
ungleich-gitea commented 2021-11-20 13:23:49 +00:00
Owner
Copy link

Created by: 4nd3r

continuation from #763

major linux distros should be main priority and freebsd should be supported as well as humanly possible. macosx, openbsd, netbsd, solaris and other ancient or esoteric operating systems shouldn't be supported as a goal and we shouldn't demand it from contributors.

for example, if we want to have something like #746 some day, then this should be decided. right now we don't actually know if all the types, which use os explorer, even work for anymore.

also, since there are so many linux distros, then using kernel_name global explorer for detection feels more reasonable than os explorer, because naming all possible distros is too much effort.

of course, there are cases where you have to check distro, but if we talk about global explorers, then most linux distros have same functionality available for those. and starting with global explorers, we should first support linux this way and fallback for unknown os should always be empty result, not an assumption.

*Created by: 4nd3r* continuation from #763 major linux distros should be main priority and freebsd should be supported as well as humanly possible. macosx, openbsd, netbsd, solaris and other ancient or esoteric operating systems shouldn't be supported as a goal and we shouldn't demand it from contributors. for example, if we want to have something like #746 some day, then this should be decided. right now we don't actually know if all the types, which use `os` explorer, even work for anymore. also, since there are so many linux distros, then using `kernel_name` global explorer for detection feels more reasonable than `os` explorer, because naming all possible distros is too much effort. of course, there are cases where you have to check distro, but if we talk about global explorers, then most linux distros have same functionality available for those. and starting with global explorers, we should first support linux this way and fallback for unknown os should always be empty result, not an assumption.
ungleich-gitea commented 2021-11-20 15:38:22 +00:00
Author
Owner
Copy link

Created by: telmich

@krytarowski It was a joke, but if you really ask: if you see the age, maturity and longevity of NetBSD, you can certainly call it ancient. It has been there like... what? forever? Fits the definition of ancient.

*Created by: telmich* @krytarowski It was a joke, but if you really ask: if you see the age, maturity and longevity of NetBSD, you can certainly call it ancient. It has been there like... what? forever? Fits the definition of ancient.
ungleich-gitea commented 2021-11-20 15:38:24 +00:00
Author
Owner
Copy link

Created by: 4nd3r

nice morning - @telmich already bully BSD users 😈 actually, if you think about it... netbsd's strength is portability and we try to code portable cdist types... ergo we should definitely support NetBSD as a litmus test!

*Created by: 4nd3r* nice morning - @telmich already bully BSD users :smiling_imp: actually, if you think about it... netbsd's strength is portability and we try to code portable cdist types... ergo we should definitely support NetBSD as a litmus test!
ungleich-gitea commented 2021-11-20 15:38:25 +00:00
Author
Owner
Copy link

Created by: krytarowski

Rationale for say being ancient?

*Created by: krytarowski* Rationale for say being ancient?
ungleich-gitea commented 2021-11-20 15:38:26 +00:00
Author
Owner
Copy link

Created by: telmich

@krytarowski Clearly both. Any other question?

*Created by: telmich* @krytarowski Clearly both. Any other question?
ungleich-gitea commented 2021-11-20 15:38:27 +00:00
Author
Owner
Copy link

Created by: krytarowski

Just making sure, is NetBSD ancient or esoteric?

*Created by: krytarowski* Just making sure, is NetBSD ancient or esoteric?
ungleich-gitea commented 2021-11-20 15:38:29 +00:00
Author
Owner
Copy link

Created by: jdguffey

Agreed with @telmich. It's been a few years since I contributed to the project, but hasn't the general rule been "support POSIX," so that we wind up supporting everything unless it departs from that standard? That way, if something departs, we could either support it because it's widely enough used (GNU/Linux) or not we don't see enough value in writing new code to support it (MINIX, et al), though individual contributors could choose to write OS-specific code if it fits their use case?

*Created by: jdguffey* Agreed with @telmich. It's been a few years since I contributed to the project, but hasn't the general rule been "support POSIX," so that we wind up supporting everything unless it departs from that standard? That way, if something departs, we could either support it because it's widely enough used (GNU/Linux) or not we don't see enough value in writing new code to support it (MINIX, et al), though individual contributors could choose to write OS-specific code if it fits their use case?
ungleich-gitea commented 2021-11-20 15:38:30 +00:00
Author
Owner
Copy link

Created by: telmich

I think the answer here is very simple: scratch your on itch. We support what we, the cdist community, uses.

And if we don't have support in a type or an explorer, we error out and ask the user to add support.

That said, we try in general to code portable (i.e. prefer posix over bash), but we don't squeeze in portable support, where it is too much pain.

*Created by: telmich* I think the answer here is very simple: scratch your on itch. We support what we, the cdist community, uses. And if we don't have support in a type or an explorer, we error out and ask the user to add support. That said, we try in general to code portable (i.e. prefer posix over bash), but we don't squeeze in portable support, where it is too much pain.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
7.0
6.9
py3.10
ander/__package_apt_update_index
haproxy-dualstack
ander/__sed
beta
ander/os_version_debian_sid
evilham-compatibility-fixes
ander/__rsync
__snakeoil_cert
ander/update_readme
__download_improvements
feature/onchange
cleanup/string-formatting
feature/type-relationship-graph
cleanup/ssh-auth-keys-types
__letsencrypt_cert-fix-hooks
bugfix/preos-debug
bugfix/in-script-import
6.8
bugfix/sphinx-docs-build
6.7
cherry-pick-2f433a14
bugfix/make-code-consistent
6.6
regain-py3.2-support
6.5
bugfix/multiple-log-lines
matterbridge
coturn
alpinefix
matrix
new-type/network-interface
feature/process
6.4
feature/info-command
feature/libexec
6.3
preos-plugins-dir-opt
gitlab-ci
6.2
order-dep-fix
6.1
6.0
build/support-pip-from-git
feature/shell-lib
5.1
feature/support-type-deprecation
5.0
feature/python-types
4.11
4.10
shellcheck
4.9
4.8
freebsd-improvements
new-prometheus
key_value-onchange
feature/output_streams
AnotherKamila-patch-1
__letsencrypt_cert-fixes
letsencrypt-cron-fix
4.7
newtype-__letsencrypt_cert
os_explorer_devuan_fix
prometheus-exporter-fixes
daemontools-for-fbsd
type-prometheus-exporter-from-master
prometheus-more-fixes
4.6
4.5
fix-j
steven-backport
4.4
prometheus-fixes
grafana_dashboard
prometheus
daemontools
consul_improvements
feature/trigger
4.3
4.0-pre-not-stable
4.2
4.1
4.0
feature_install_and_preos
3.1
no-dot-cdist
random_dot_cdist
feature_yum_url
feature_files_export
3.0
2.3
2.2
2.1
ssh_callback
2.0
archive_shell_function_approach
1.7
1.6
1.5
1.4
1.3
1.2
1.1
1.0
7.0.0
6.9.8
6.9.7
6.9.6
6.9.5
6.9.4
6.9.3
6.9.2
6.9.1
6.9.0
6.8.0
6.7.0
6.6.0
6.5.6
6.5.5
6.5.4
6.5.3
6.5.2
6.5.1
6.5.0
6.4.0
6.3.0
6.2.0
6.1.1
6.1.0
6.0.4
6.0.3
6.0.2
6.0.1
6.0.0
5.1.3
5.1.2
5.1.1
5.1.0
5.0.2
5.0.1
5.0.0
4.11.1
4.11.0
4.10.11
4.10.10
4.10.9
4.10.8
4.10.7
4.10.6
4.10.5
4.10.4
4.10.3
4.10.2
4.10.1
4.10.0
4.9.1
4.9.0
4.8.4
4.8.3
4.8.2
4.8.1
4.8.0
4.7.3
4.7.2
4.7.1
4.7.0
4.6.1
4.6.0
4.5.0
4.4.4
4.4.3
4.4.2
4.4.1
4.4.0
4.3.2
4.3.1
4.3.0
4.2.2
4.2.1
4.2.0
4.1.0
4.0.0
3.1.13
tn1
3.1.12
3.1.11
3.1.10
3.1.9
3.1.8
3.1.7
3.1.6
4.0.0pre3
3.1.5
3.1.4
3.1.3
3.1.2
3.1.1
3.1.0
4.0.0pre2
3.0.9
3.0.8
3.0.7
3.0.6
3.0.5
3.0.4
3.0.3
4.0.0pre1
3.0.2
3.0.1
3.0.0
2.3.7
2.3.6
2.3.5
2.3.4
2.3.3
2.3.2
2.3.1
2.3.0
2.2.0
2.1.2
2.1.1
2.1.0
2.1.0pre8
2.1.0pre7
2.1.0pre6
2.0.15
2.1.0pre5
2.1.0pre4
2.1.0pre3
2.1.0pre2
2.1.0pre1
2.0.14
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.1
2.0.0
1.7.1
1.7.0
1.6.2
1.6.1
1.6.0
1.5.0
1.4.1
1.4.0
1.3.2
1.3.1
1.3.0
1.2.0
1.1.0
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
0.9.9
0.9.8
0.9.7
0.9.6
0.9.5
0.9.4
0.9.3
0.9.2
0.9.1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
Labels
Clear labels   
bugfix

   
cleanup

   
discussion

   
documentation

   
doing

   
done

   
feature

   
improvement

   
packaging

   
Stale

   
testing

   
TODO
No labels
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#95
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?