On Sun, 3 Jan 2010, Viktor Szakáts wrote:
most things below are just scratching the problem-surface, and
definitely need more eyes.
> I have a pending commit, which merges core + lib + static
> rpms into one. Is this okay?
definitely not.
i think that the proper splitting is something very close to this (as
i'm primarily familiar with deb, that's what i base the following
upon, but the general principle applies with most every distro, and to
some extent ports, pkgsrc, and whatever other packaging method there
is):
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to &.x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling prg to native code
harbour-doc - stuff in doc/
libharbour-foo - a "foo" component with the foo.so.x.y.z
libharbour-foo-dev - headers for this foo.so.x.y.z, and foo.so (link
to foo.so.x.y.z)
of course with carefully crafted dependencies between these, where
internal dependencies between tools and stuff may further change the
scene.
as you can see, there is a lot of the above that is not there in the
build system.
the first problem is a consistent shared library versioning policy.
currently the so version is stuck to the harbour version number, which
is suboptimal. it has had the same version number for quite some time,
with api and maybe abi changes too, this is bad karma. there needs to
be a procedure stating "if you change abi in an incompatible way, bump
major; if you change abi in a compatible way, bump minor; if unsure,
bump", or something along these lines.
this is a strict prerequisite for any libharbour package, which in
turn is a strict prerequisite for (other, 3rd party) stuff written in
harbour entering any distro (which i suppose is an implicit goal,
otherwise there's no point in harbour itself entering any distro).
this only covers libharbour, and does not even begin to scratch the
stuff that is currently only shipped in static archives. it seems to
be customary not to make shared versions of these; i haven't yet
figured out whether this is good or bad (i can reason either case,
though :).
yes, this detaches libharbour version from the actual harbour version,
but it also makes it possible (with some extra tweaks i s'pose) to
have several libharbour versions installed, which is good for example
if there is a "harbour-2.0" package with the release version, and a
"harbour-be" (for bleeding edge) version updated regularly, thus
making it possible for a developer (harbour user, who develops in
harbour, but who does not develop harbour) to have a stable
development environment as well as be able to test new features,
follow new features (maybe in a separate branch in her application),
and also report bugs with the development version of harbour.
libharbour also needs some baseline functionality. what this means is
that no matter where, on what system, in what environment, etc etc, is
a libharbour.so.x.y.z is generated, any other libharbour.so with the
same x.y.z version generated on any other system in any other
environment need to have at least a well-defined common ground (call
it "core functionality"), ideally be the same. what this actually
means is up for definition (eg. what rdds, what gts, etc etc).
optional (everything the above does not cover) is to be supplied in
separate {libraries, archives, ...} maybe by libharbour dlopening them
on demand, or whatever.
consider this: "i have application `foobar', it uses
libharbour-4.3.11, and it crashes when i look to the left. the
backtrace says `system has been recalled'". currently basically
there's no way to tell what actually *is* in libharbour-4.3.11, making
debugging in email (which *will* happen, when we're there) nigh
impossible. mix and match this with the currently non-existing
consistent shlib versions, and it quickly translates to "hm,
libharbour-4.3.11. we have absolutely no idea what it might be."
then there's the question of packaging the contrib stuff, possibly
creating packages that support cross-compiling (the picture starts to
get blurry now -- see, you don't, for example, package gtwvw for a
native package, but you do for a cross-compile environment).
then there's the question of (again) packaging the contrib stuff - do
we want a separate package for each (i can reason pro and con against
either), or do we want to group them by some attributes (i can reason
pro and con against either) (though my preference is this latter), ...
at this point i literally got tired of citing the issues, as in i
really need a coffee, but i'm pretty much certain that by now everyone
sees that it is _rather a complicated issue_.
> 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.
maybe this is why distros (debian at least) is not really fond of
upstream doing the packaging :) on the other hand, some debian
packages tend to be f*ed up beyond all recognition, so downstream
can't entirely be let on her own either ;)
> 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
sus doesn't come to play here (it doesn't really have anything to do
with packages; if it does, noone uses it anyway, including the branded
unixes :).
lsb is only a marginal concern; the main point is adhering to fhs,
which the packaging level policies require anyway.
bullet point #4 will mostly be taken care of by the package building
procedure itself (eg. do man pages need to be compressed, where to put
readme.txt, should LICNSE be included, ...).
once the above longer part is ironed out, these four points will
mostly iron themselves out.
> Some contradictions are expected, f.e. LSB doesn't support
> DEB, anyway it's no question we must support it.
again, this is only of a concern for binary-only packages, or with a
single unified package for every and all lsb-compliant distro. neither
is what we are after right now.
> > 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?
this i have scratched above.
> Watching the chaos and total _enduser_ unfriendliness
agreed.
> in the Linux world, I'm a little bit worried now about the
> price to pay to become part of this system.
it's a lot. but, on one hand, that's what packagers are for. on the
other hand, there hasn't been an overwhelming storm of volunteers
(from outside these circles) to create packages for any distro, so i
guess we are on our own.
> Linux was unable to reach a common packaging method in
> 15 years. (No wonder it doesn't catch up on the desktop)
chaos is part of the culture. it's revolution, not evolution. this is
a *statement*, and i'm deliberately not sharing my *opinion* on this
matter ;)
> 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.
in principle, it's not a bit different from building a windows
installer. it's just as $platform-specific, but it's not only one
platform ("distro"), but many, with a radically different life-,
evolution-, development- and usage-cycle from that of windows (or os2,
or even commercial unixen, or even from each other (just compare the 7
or so years life cycle of rhel with the 6mo fedora releases).
> Worst case we can maintain patches which implement these
> whatever requirements of each distribution we may want to
> support.
most of the needed things (maybe all of them, save the so version
thing) doesn't as much need patches as it needs an executive decision:
"we do it this way". the rest can then be adjusted accordingly.
obviously, it's best if "our way" is sufficiently close to the
packaging needs and common sense in order for the adjustments to be
bearable, but i believe harbour (as in `upstream') can also benefit
some from the `downstream way', as can downstream benefit from
upstream.
reiterating again: this is scratching the surface, stating the core
problems (maybe exaggerating at times, but that is only for
illustration purposes :), and calling for a discussion. i'm especially
expecting przemek to chime in, since he seems to be the resident
rpm-expert as well ;)
--
[-]
mkdir /nonexistent
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
