> note it says "packaging policy", not "packaging suggestions". > > proper packaging is much more complicated and tricky business than > most of you can even begin to imagine, and it most certainly isn't > just "lets shovel a metric shitload of files into an rpm (or deb, or > anything else, for that matter) container and call it a day".
I have a pending commit, which merges core + lib + static rpms into one. Is this okay? We can rename it to anything, although I have to wonder about these policies... This policy is OpenSUSE specific. Now if each distro has its own policy (and why not, I bet they have), we will have some fun waste of time trying to satisfy all of them. I'm naiv, but I'd think there must exist some RPM / DEB level policies which are idealistically in sync with downstream distro policies. If there are such policies, first we should try to stick to them. So to sum it up, I propose these priorities when it comes to cleanup up our RPM / DEB support: 1. general *nix policies (SUS) 2. general Linux policies (LSB) 3. RPM / DEB packaging level policies 4. distro specific policies Some contradictions are expected, f.e. LSB doesn't support DEB, anyway it's no question we must support it. > as things stand now, as far as i can tell (this is a long shot, and a > premature statement from my side, but hey) the upstream build system > and upstream procedures aren't even able to support proper packaging. What is exactly missing? Watching the chaos and total _enduser_ unfriendliness in the Linux world, I'm a little bit worried now about the price to pay to become part of this system. For a start, Linux was unable to reach a common packaging method in 15 years. (No wonder it doesn't catch up on the desktop) Seems we will be forced to use some tools which will try to pull us to become Linux specific, instead of being portable/multiplatform. We should try to avoid this. Worst case we can maintain patches which implement these whatever requirements of each distribution we may want to support. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
