On Sun, 3 Jan 2010, Viktor Szakáts wrote:
> > 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.
naturally there are dependencies between them, also external deps as
needed.
> 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 might be misunderstanding something, but this seems to be untrue. i
have a hbrun binary that (to a certain extent) chugs along nicely,
without any trace of a dynamic libharbour (or anything else harbour)
being around anywhere.
> 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.
hbrun's script interpreter mode is the prime example of the contrary.
also imagine przemek coming up with (arbitrary example) an ads-like
"dbf server", which relies on and only relies on libhb (file
management, network management, dbf drivers, full stop). should the
compiler and headers, and contrib/rddads be installed in this case?
hardly.
> 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.
yes, of course. i deliberately didn't go into such details for fear of
being lost in them.
> > 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.
ok, i accept that. i still think that bumping as changes go would be
better, but i accept that.
> > 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?).
i feel they also should be, but this also raises libver questions. do
they live a separate life, or do we go with one and only one version
for the whole shebang?
> > 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.
certainly. in a static world, none of this thread applies at all. in
that case, any harbour package is only used by a developer
(application developer writing prg code, producing executables that
only (dyn)link against stuff outside harbour), thus making the whole
"proper package" idea moot at best, as any package becomes "just" a
convenience container, for which the current setup is ok. won't ever
enter any distro, but if no end-user is ever to use it, then it
doesn't matter either.
> > 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
no, no. i'm not talking "versions", i'm talking "instances". both you
and i have r13450 sources. you build on your system, i build on mine.
can you be sure we have a libharbour.so with the exact same
functionality? no, you can't.
btw, is this api or abi compatibility that is promised?
> would just effectively halt development and force us to
> concentrate on nothing else, but compatibility.
i fail to see why, but let's not get lost in this detail. i'll just
accept your point.
> 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 flat out can not be true ;)
if you have slang-dev installed and i don't, you get a libharbour with
gtslang, i get one without. same sources, system-dependent result.
take glibc as an example. the getpwnam function. this is quite very
core of a functionality to glibc, yet you will only find stubs in
glibc.so - because the backing store for storing user accounts can be
files, berkeley db, ldap, nis, whatever. consequently, the actual
implementation lies in libnss_files.so (for a file backing store),
libnss_nis.so (for nis), etc. the actual implementation is loaded on
demand by glibc (which also severely affects static linking glibc
(read, you can't), but hb needs not follow that particular segment of
the path ;)
analogously, it could be so that gtnul is always built into
libharbour.so proper, and a number of gt*.sos are built as well. if
you request gtsln, the requisite gtsln.so is dl'ed by libharbour, and
all is well. if for any reason it can't be linked in, you get a
runtime error.
dunno how that affects hbmk and linking, tho.
a couple of cycles more at application startup, yes, but we are not on
z80 cp/m anymore ;). the upside is that you get consistent libharbour
with controllable dependencies (why exactly should i install this 1.5
meg worth of libslang onto a pos machine with 4 megs of flash
otherwise using curses for it's character cell display? why should i
install 60 megs worth of x junk onto this server that only runs
przemek's latest "dbf server"? linux people tend to think this way ;),
and, at times, some of these points actually make sense).
> 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.
this hierarchy can nicely be reflected in the packages.
> > 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.
i'm growing to think we should, for reasons outlined above.
> > 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).
i apparently wanted to note something in here too, but i completely
forgot what that might have been...
> > 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.
which one do you want me to argue for? :)
regardless, it is true that the safest is probably the second.
> 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.
yes, that is a good idea.
> harbour-core
> harbour-contribs ("virtual" package)
> harbour-hbct
> harbour-hbtpathy
> harbour-hbmisc
> ...
> harbour-bindings ("virtual" package)
> harbour-hbfbird
> harbour-hbodbc
> ...
this could be a fine starting point, but (surprise! :) it is not
without side effects.
say there's harbour-bindings version 0, depending on fbird, odbc, pg.
somewhere along the line odbc gets dropped from svn. now, at next
release, harbour-bindings version 1 will depend on fbird and pg, so
fbird and pg will not get upgraded (as they are blocked by the fact
that the package manager won't want to remove odbc). if you muscle in,
and upgrade bindings anyway, you'll pretty silently lose odbc.
this is perfectly normal this way, i'm just spelling this out for all
aspects to be known. *i* know this and read upgrades carefully (still
can't tell you how many times have i been bitten in the.. bottom), but
i think most of the target audience doesn't have 15 years of systems
experience behind their belts. and just like that, we have two groups
of people with only marginally overlapping needs, both needs to be
catered for ;)
> >> 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.
i think these are pretty orthogonal. the established procedure of
using (in the code) only features available in some widely recognised
standard works out real nice. anything else there's no universal
agreement for. i'd be happy to arrange a meeting, gear up my office
with exotic stuff, and show you how unix, unix and unix look, swim and
quack completely differently, over a sizeable cup of coffe ;)
> > 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.
some redhat people will have to chime in, i'm afraid that's about as
far as my rpm skills go. maybe istvan wants to get on board? :)
> 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.
this may very well be the case. or it may not. i honestly have no of
that level of difference between suse, rh, pld, and whatnot using rpm.
> > 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.)
me, my last encounter with windows as my desktop was freshman year at
college, playing tie fighter. i have never for one split second
considered giving parents anything but windows. makes them happy,
consequently makes me happy ;)
> 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.
again, orthogonal. what is built by the current process needs to be
built for the packages as well. what needs to be decided is the
grouping of these components based on various criteria:
- customs and practices
- policies
- subsystem interdependencies
- usw usw.
the autohell (or any of the alternatives) aid in porting the code,
which is currently done by strategically placed ifdefs in a couple of
places. currently, i don't think any such thing is desperately needed.
przemek hints some level of auto* usage every now and then, and i'm
sure he'll come up with just the right level of integration, whatever
that might be.
> > 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.
what does that mean? is it time for feature requests? :) i'm thinking,
maybe this should be the spot where building cross-compiler packages
could get some support? not that i'd have any more specifics at this
moment. maybe a quick look at some existing crosscompiler package
could give an idea or two.
--
[-]
mkdir /nonexistent
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
