FHS compliance long term project.

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
PrzemoF
Posts: 3008
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

FHS compliance long term project.

Postby PrzemoF » Tue Jun 02, 2020 12:19 pm

It's long overdue and it will be painful. If you don't know what FHS means please check this [1]. This is something that will make life of all people involved in packaging FreeCAD for any linux system much easier. Some reference links:

1. https://tracker.freecadweb.org/view.php?id=4352
2. https://github.com/FreeCAD/FreeCAD/pull/3525

The goal: make FreeCAD FSH compliant

Road map:
1. Identify what is currently being installed in non-FHS compliant location
2. Assess potential problems when moving files on different systems. Info from packagers for windows, flatpack etc. wil be required.
3. Assess if the problem can be solved with atomic approach or it should be one massive change and recovery from broken things.
4. Get green light from the core devs
5. Make PR/PRs

Please share your thoughts/opinions/concerns especially if you're involved in developing FreeCAD code, packaging or testing.

[1] https://en.wikipedia.org/wiki/Filesyste ... y_Standard
vocx
Posts: 4332
Joined: Thu Oct 18, 2018 9:18 pm

Re: FHS compliance long term project.

Postby vocx » Tue Jun 02, 2020 4:35 pm

PrzemoF wrote:
Tue Jun 02, 2020 12:19 pm
...
Please share your thoughts/opinions/concerns especially if you're involved in developing FreeCAD code, packaging or testing.
It's good, and I'm glad somebody is taking the initiative. Unfortunately, most of us just keep using the default CMake files as they are, and as long as it works in our systems, we have no reason to change them. But if this really helps packaging, I welcome it.

From Arch and Draft side, I can say the pull request just adds a few variables to the installation directories, so it looks good.
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.
User avatar
PrzemoF
Posts: 3008
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: FHS compliance long term project.

Postby PrzemoF » Wed Jul 01, 2020 9:18 am

The default locations of installation
Attachments
FreeCAD_installation_locations.txt
(85.3 KiB) Downloaded 13 times
Swen
Posts: 2
Joined: Sat Oct 20, 2018 11:21 am

Re: FHS compliance long term project.

Postby Swen » Wed Jul 01, 2020 2:30 pm

I think it is time to have a good look at the build system. I would love to help out with that.

-- Swen
User avatar
hobbes1069
Posts: 246
Joined: Wed Nov 09, 2011 3:49 pm
Location: Southaven, MS

Re: FHS compliance long term project.

Postby hobbes1069 » Wed Jul 01, 2020 3:08 pm

Swen wrote:
Wed Jul 01, 2020 2:30 pm
I think it is time to have a good look at the build system. I would love to help out with that.
Would adding you to my fork which has the pull request be a good way of doing that? No point in re-inventing the wheel.

https://github.com/hobbes1069/FreeCAD/tree/fork/master

Thanks,
Richard
wmayer
Site Admin
Posts: 15971
Joined: Thu Feb 19, 2009 10:32 am

Re: FHS compliance long term project.

Postby wmayer » Wed Jul 01, 2020 3:59 pm

Please share your thoughts/opinions/concerns especially if you're involved in developing FreeCAD code, packaging or testing.
It's for around a year now that we use CMake's GNUInstallDir module which defines the variables
CMAKE_INSTALL_BINDIR
CMAKE_INSTALL_SBINDIR
CMAKE_INSTALL_LIBEXECDIR
CMAKE_INSTALL_SYSCONFDIR
CMAKE_INSTALL_SHAREDSTATEDIR
CMAKE_INSTALL_LOCALSTATEDIR
CMAKE_INSTALL_RUNSTATEDIR
CMAKE_INSTALL_LIBDIR
CMAKE_INSTALL_INCLUDEDIR
CMAKE_INSTALL_OLDINCLUDEDIR
CMAKE_INSTALL_DATAROOTDIR
CMAKE_INSTALL_DATADIR
CMAKE_INSTALL_INFODIR
CMAKE_INSTALL_LOCALEDIR
CMAKE_INSTALL_MANDIR
CMAKE_INSTALL_DOCDIR

Is it possible to define these variables in the packaging script of a distribution to make it FHS compliant? Would FreeCAD still work?

Is achieving FHS compliance also recommended for really big packages like LibreOffice? When I started the Debianization of FreeCAD 10 years ago I used LibreOffice as a template and under Debian most of the files were under /usr/lib/libreoffice and further sub-directories. So, I did it the same way and it was accepted by the Debian guys.

When the shared libraries really go to /usr/lib then I guess it won't be longer possible to install different versions of FreeCAD on a system like it's currently possible for Ubuntu and our PPA.

On the Wiki site about FHS there is no specific directory defined where Python stuff should go to. What would be the correct directory?

The Python extension modules of FreeCAD (Part.so, Mesh.so, ...) are hybrid files, i.e. on the one hand they are really shared libraries and when you implement a new FreeCAD module in C++ you could link to them but on the other hand these are Python modules. So, where should these files go to?
Swen
Posts: 2
Joined: Sat Oct 20, 2018 11:21 am

Re: FHS compliance long term project.

Postby Swen » Wed Jul 01, 2020 9:13 pm

hobbes1069 wrote:
Wed Jul 01, 2020 3:08 pm
Swen wrote:
Wed Jul 01, 2020 2:30 pm
I think it is time to have a good look at the build system. I would love to help out with that.
Would adding you to my fork which has the pull request be a good way of doing that? No point in re-inventing the wheel.

https://github.com/hobbes1069/FreeCAD/tree/fork/master

Thanks,
Richard
I can have a look at the pull request, but I am thinking more in general. It looks like the build system is carrying a lot of cruft with it that might need some cleaning.

-- Swen
User avatar
hobbes1069
Posts: 246
Joined: Wed Nov 09, 2011 3:49 pm
Location: Southaven, MS

Re: FHS compliance long term project.

Postby hobbes1069 » Wed Jul 01, 2020 9:49 pm

wmayer wrote:
Wed Jul 01, 2020 3:59 pm
Please share your thoughts/opinions/concerns especially if you're involved in developing FreeCAD code, packaging or testing.
It's for around a year now that we use CMake's GNUInstallDir module which defines the variables
Yes, it uses them, but not necessarily correctly or consistently.
Is it possible to define these variables in the packaging script of a distribution to make it FHS compliant? Would FreeCAD still work?
No, not currently, there are some paths generated some of the C code that would now be incorrect, and while probably not a huge job to fix, not insignificant, which it hasn't been done.
Is achieving FHS compliance also recommended for really big packages like LibreOffice? When I started the Debianization of FreeCAD 10 years ago I used LibreOffice as a template and under Debian most of the files were under /usr/lib/libreoffice and further sub-directories. So, I did it the same way and it was accepted by the Debian guys.
It's not absolutely required, as I got it into Fedora by dumping everything into /usr/lib{,64}/freecad and symlinking the binaries back to /usr/bin but it's messy, and a lot of non-arch data is going into arch specific locations (more below).
When the shared libraries really go to /usr/lib then I guess it won't be longer possible to install different versions of FreeCAD on a system like it's currently possible for Ubuntu and our PPA.
Can't speak to that, in general, most packages are not designed to be parallel installable outside of compat type packages. Or "alternatives" which allows multiple java stacks but only one default.
On the Wiki site about FHS there is no specific directory defined where Python stuff should go to. What would be the correct directory?

The Python extension modules of FreeCAD (Part.so, Mesh.so, ...) are hybrid files, i.e. on the one hand they are really shared libraries and when you implement a new FreeCAD module in C++ you could link to them but on the other hand these are Python modules. So, where should these files go to?
At least on Fedora, pure python modules would go into /usr/lib while arch python modules (i.e. .so libraries) go into the appropriate location depending on if they are 32 or 64 bit. (/usr/lib or /usr/lib64). Debian has a arch tuple that works similarlly.

Thanks,
Richard
User avatar
looo
Posts: 3344
Joined: Mon Nov 11, 2013 5:29 pm

Re: FHS compliance long term project.

Postby looo » Thu Jul 02, 2020 4:12 am

hobbes1069 wrote:
Wed Jul 01, 2020 9:49 pm
At least on Fedora, pure python modules would go into /usr/lib while arch python modules (i.e. .so libraries) go into the appropriate location depending on if they are 32 or 64 bit. (/usr/lib or /usr/lib64). Debian has a arch tuple that works similarlly.
I guess python should go into use/lib/pythonx.y/site-packages. This is totally possible with new-style modules which extend the freecad namespace use/lib<xx>/python<x.y>/site-packages/freecad. But going this way we remove the possibility to install multiple versions of freecad into the same environment, which is possible for Ubuntu (not sure about fedora). In my eyes it's a good decision, but I am not sure everyone is happy with that.
User avatar
kkremitzki
Posts: 2032
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: FHS compliance long term project.

Postby kkremitzki » Thu Jul 02, 2020 4:53 am

wmayer wrote:
Wed Jul 01, 2020 3:59 pm
Is achieving FHS compliance also recommended for really big packages like LibreOffice? When I started the Debianization of FreeCAD 10 years ago I used LibreOffice as a template and under Debian most of the files were under /usr/lib/libreoffice and further sub-directories. So, I did it the same way and it was accepted by the Debian guys.
As long as it's just .so and .a files in there, something like /usr/lib/libreoffice is fine according to the FHS. In fact it's a good idea if you have generic shared library names to namespace them in this way.

It should ideally be arch-specific too so for example on Debian it should be /usr/lib/x86_64-linux-gnu/freecad. And the directory can be versioned too so the path could end with freecad-0.19 for example. Then we would also have e.g. /usr/include/x86_64-linux-gnu/freecad-0.19 for any .h files. Everything else should go in e.g. /usr/share/freecad-0.19, potentially even Python packages and modules, if we consider them to be internal to FreeCAD. If they should be available on the system level though they should be in /usr/lib/python3/dist-packages.
The Python extension modules of FreeCAD (Part.so, Mesh.so, ...) are hybrid files, i.e. on the one hand they are really shared libraries and when you implement a new FreeCAD module in C++ you could link to them but on the other hand these are Python modules. So, where should these files go to?
It's fine for Python .so files to be in /usr/lib/python3/dist-packages but probably not directly into that directory since the names are somewhat generic, there should be a /usr/lib/python3/dist-packages/freecad.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.