> 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)
What is the point of having 'harbour' package, when
nothing useful can be done with it? In any case, hbmk2
needs to be moved to utils since it requires libs to
work.
Then what is the point of having hbrun without dynamic
libs, when hbrun is built as shared binary in certain
situations, so it cannot work without Harbour dynamic
lib also.
I think the ultimate difference between Harbour and
regular 'lib' packages, is that in Harbour there is
not much point in having a "dev" packages, as development
consists of building final apps in 99.99% of cases,
and not building something else with the help of Harbour
headers.
harbour compiler executable can do very little thing
by itself, as far as real-life usage goes.
Here comes to mind, that maybe we should also list
C compiler tools as dependency, because without C
compiler, Harbour is again unusable.
> 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
We've been in development stage. Version in increased
by each major release, and we promise to keep compatibility
between minor releases only. Emphasis on _release_. Current
SVN, beta, or rc isn't a release.
> 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.
We have that, see above.
> 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, shared lib creation for contribs is not implemented
(yet?).
> 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.
This is only possible in pure dynamic world I guess.
> 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).
I'd personally define "get Harbour lib version" as the only
core functionality which we promise to be compatible across
all version. I don't see a point in limiting ourselves, as it
would just effectively halt development and force us to
concentrate on nothing else, but compatibility.
As for the expected _set of content_, I agree we should have
a standard defined, and it's defined well already.
It's roughly everything inside /src except compiler. We call
this "Harbour core". [ The only place this can be violated
is an extra undocumented build option to mash together core
dynamic lib with contribs libs, something I've been arguing
against recently. ]
Above this are contribs, which are independent of each
other and independent of core, utilizing official Harbour
APIs only, plus they may have extra external dependencies.
> optional (everything the above does not cover) is to be supplied in
> separate {libraries, archives, ...} maybe by libharbour dlopening them
> on demand, or whatever.
We don't have dynamic versions of these libs.
> 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), ...
I'd personally favor a system where standalone (with no
external dependencies) contribs would be packaged inside
one 'contribs' package, while the rest of them (with
external dependencies) are packages separately one by one
to avoid pulling in all the dependencies at once. This
latter group is often called 'wrappers', 'bindings', but
it can be more in a few cases, like rddsql.
But, technically there is nothing against packaging
every contrib separately and this resonates better with
the notion to look at every contrib as a fully independent
entity, with to possibility to attach and detach them
from Harbour SVN.
Probably the cleanest would be this second option.
I guess we could have 'virtual' packages also, which
would have no other purpose than 'pulling' in all
contribs, or just contrib without external dependencies,
or 'popular' libs.
harbour-core
harbour-contribs ("virtual" package)
harbour-hbct
harbour-hbtpathy
harbour-hbmisc
...
harbour-bindings ("virtual" package)
harbour-hbfbird
harbour-hbodbc
...
> 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_.
No doubt.
>> 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 :).
I meant this not just for packaging, but as a general priority
when making decision.
> lsb is only a marginal concern; the main point is adhering to fhs,
> which the packaging level policies require anyway.
FHS, of course, I meant the rest of global standard
as the same level as LSB, LSB was in fact just one example.
> 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, ...).
Hopefully ;) But as long as we have "OpenSUSE" packaging
docs around, I don't see a strong guarantee to it.
What if OpenSUSE "requires" to use "-devel" and Red Hat
doesn't. Until yesterday I expected these policies are
laid on the package type level.
> 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.
We have to do it, that's for sure, unless Google
or some other large entities pick up Harbour, but
chances are quite slim ;)
>> 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 ;)
Well, it's a long topic, and if chaos could create
Linux, it could kill it as well. For now we can only
decide to support or not support some or all of the
"standards" and watch things to happen. It stays
to be a serious problem though which limits adoption
on Linux. (see long and heated discussion on this
list form last year, when I complained why I would
not buy a Linux desktop for my parents or gf.)
>> 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).
If we can keep good separation of distro creation and
our binary build process, it's good. My fear is that we
must end up using autoconf/configure/m4 and all that crap
just to create compliant distros, and become too much Linux
specific in the process. I meant we should avoid that.
If we can do it, good.
>> 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 ;)
I think we should first try to clean our dir layout.
It will be painful, but beneficiary and it's planned already.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
