I’m Dmitry Marakasov, Free Software developer. My primary languages are C++ and Python, interests include FreeBSD, software packaging, software portability, F/OSS gamedev and improving Free Software, Hardware, and Data ecosystem in general. I try to contribute to everything I can get my hands on.
My most notable projects and contributions are:
- I maintain over 350 ports and have made over 15k commits to FreeBSD ports collection.
- I’m author of Repology, a service which aggregates packaging information from over 300 repositories for the benefit of software authors and package maintainers.
- I maintain some C++ libraries:
- I maintain some Python modules:
- I’ve reimplemented XKCD #1608 “Hoverboard” game as a native application.
- I maintain some third party projects abandoned by their authors:
- In the past I’ve actively contributed to OpenStreetMap and have written some related tools:
- I took part in making classic Vangers game cross-platform and available under Linux.
- I’ve contributed to hundreds other F/OSS projects.
That is roughly what I write about in this blog.
It is tempting to enable some (generally useful) compiler flags
-march=native in you build by default
(such as to discover more problems and generate more efficient
code), however in practice these flags may lead to packaging problems
Surprisingly, portability/packaging issues may be introduced to a project long before the first line of code is even written, merely by a bad name choice.
Make sure the name of your project is clear, unambiguous, unique and compatible with packaging, otherwise the package or files installed by it are likely to be named differently than you’ve intended (to avoid name conflicts, comply with packaging policies, or just because of misunderstanding). This, in turn, causes trouble for users locating and running your software and breaks automated tools (such as new upstream release checkers and security vulnerability reporters). In addition, these changes are likely be different in each other repository, which complicates distro migration and hinders interoperability, portability of dependent software and usefulness of documentation.
As promised, I’m staring a series of posts about F/OSS portability which, hopefully, I will be able to compiles into something like a book at some point
For 15 years already I create and maintain FreeBSD ports of different F/OSS software, and forgetfully I have to state that the process has not become easier in any way during this time. What’s the cause?