Where are the packaging rules for OpenMandriva?
Any packaging rules for tool-chain packages and libraries? ( glibc, gcc, clang, binutils, ect.)
Are there any rules for packaging out-of-tree kernel modules? (nvida, virtualbox, ect.)
Also when major packages like kernel, glibc, gcc, clang, binutils, systemd, ect. are updated is there any type of announcement? Is there any policy regarding such announcements?
Don’t the above things seem like necessary basic things for a Linux disto to have?
These are very interesting questions I searched an answer when I began to use my personal repository so I will try to report here my own answer and, partially, opinion on what I understand how these processes work in OpenMandriva. Of course the followings are only my own interpretation and may be not the official way.
Well, there are some rules nobody has had the time to write that rules on the wiki until now. Except that rules you are free to use your own personal style into .spec files but keep it clear to everyone so other people may easily read it and modify it if needed.
Usually only developers can package core programs and libraries (i.e. main repository), but you my provide path on git.
Actually for supported languages, such as C and C++, clang in the preferred compiler and you should use gcc only when it fails. You may find some help in the wiki, expecially here.
About tool-chain you may choose which among the ones provided by the sources you are compiling according to you personal skills and tastes.
Finally about out-of-tree kernel modules I can’t say.
I don’t think there is really a policy, sometimes they were announced on the blog, but not always.
Yes, as such as the time to spend to write them on the wiki 
.
Thanks @mandian. But what I’m asking here is “are there rules for everyone, especially developers”. In other words official “OpenMandriva Packaging Rules”.
And from what I’ve seen they need to be called “Rules” not “Guidlines”. That does not mean that there can’t be changes to the rules, there can and should be if warranted. (Obviously this is IMO).
The underlying question is if our tool-chain packages and libraries are in such a mess in Lx 3, and by all reports they are, then how did this happen?
And major thing leading to all of the above is how is Lx 4 release going to “fix” this unless we deal with the issue that led to the problem first and then develop and release Lx 4? In other words don’t we need goals and a plan for Lx 4 before we develop it? First Packaging rules, then a Release Plan for Lx 4.
Not in the middle of the process or as we are getting ready to start testing prior to release.
From my perspective we seem to be doing cart before horse. Hope that expression isn’t to US centric. Means we seem to have our priorities backwards. In a similar vein there is the carpenter’s saying “Measure twice cut once”. Which for us I believe would translate to “plan first fix once”. For a Linux distro “plan” means a plan for packaging as well as a Release Plan.
In business we generally find that it is easier to come up with a plan if you first have a goal. I don’t think it is rocket science to come up with a goal, more likely list of goals, for packaging. Does seem like this should be done by developers not dictated to them.
Aside: And if developers do write Goals and Rules for Packaging then it becomes incumbent that QA-Team to write Goals and Rules for Quality Assurance. This’ll put yours truly to work…
Aside-2: There needs to be some consideration for the reality of resources in the process for developers or QA. In other words since we are few in number the rules should probably be kept towards short and simple. As stated they can be changed if warranted. For instance after a fantastic Lx 4 release when our user base grows exponentially and we start getting more contributors (exponentially) so we have more people to do things.
Aside-3: But the hope and belief is that having a simple plan and simple rules would lead to a solid, sane release staying that way. Also should massively cut down on the time currently spent fixing things due to tool-chain and library confusion.
ASAIK developers know all the ruels and everyone can learn them by reading into SPES files, at least I did so and asked to IRC channel when something was not clear to me and I always received all the support I needed by developers.
IMHO without clear written packaging rule rules on the wiki we can’t hope people begin to contribute to packaging process.
These are points may be discussed in the next TC meeting.
OpenMandriva generally follows Fedora Packaging Guidelines and Mageia Packaging Guidelines. Library packaging and Group Tag usage follows Mageia’s guidelines (which are the only major disagreements between Fedora and Mageia).
The main exception is that OpenMandriva does not use a DistTag, as it is auto-appended to RPM’s filename by RPM for us.
Thanks, now we’re getting somewhere.
Post-edit: It may be worth noting that I am on the OM QA-Team and did not know this. Don’t know if this is ignorance on my part or something that simply isn’t well known.