>> 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.
It depends on the setup. For cases where Harbour
is built to be installed in "system locations",
the binaries are built against the shared lib.
>> 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
That's true, although hbrun is _not_ part of the
default core package we're talking about. hbrun
however, requires shared lib.
> management, network management, dbf drivers, full stop). should the
> compiler and headers, and contrib/rddads be installed in this case?
> hardly.
Well, standalone apps built using Harbour and part
of Harbour package can be like that (like hbrun),
but I think this projects primary goal is to build
a compiler, and even hbrun may need .ch header and
even such dbf server is most likely to have a client
side, which will in turn need the compiler.
What you describe fits the 'harbour-tool' category,
which is fine.
So to reiterate, maybe a "harbour-dynlibs" package,
and a "harbour-staticlibs" package are justified, but
only as long as these are always pulled by "harbour-core"
package. "harbour-tools" package would only pull
"harbour-dynlibs".
>>> 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?
Since they are meant as separate entities, we
should have the option to untie they versioning
from core anytime. Until they live inside the
same repository, we should sync their version to
core.
>>> 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.
The only thing we can guarantee is that 2.0.0 (release) will
be compatible with 2.0.2 (release), but we don't guarantee
that 3.0.0 will be compatible with any of them.
Revision-level compatibility isn't achievable, and it would
be insane to pursue such goal. It's simply unmanageable.
> btw, is this api or abi compatibility that is promised?
Ideally both.
>> 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.
That would mean every SVN revision is a final release.
Who would guarantee this promise? Or, who would try to
document all the changes in between each revision which
happens to break some compatibility details?
I think here on the dev lists users are too much given
the impression that each SVN revision is a release,
because these revisions are most of the time stable.
But: they are not.
>> 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.
I you ask me, I wanted to pull out gtcrs and gtsln from
inside the core for somewhat similar reasons, but it got
blocked by few users.
> 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.
I don't know, but we should try to gather all such
possible issue and come up with answers. There is no
other way. One thing is intent and theory and one
other is current reality.
> 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).
Fine with me. Although we need to keep a certain
amount of features to stay C5.2 compatible a provide
a common framework for Harbour apps. So such tripping
needs should stop at one point.
>>> 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.
Should be developed, that's all ;) I have nothing
against it fundamentally.
>>> 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.
No doubt this can be argued, I told my current POV,
given current information.
>> 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 ;)
I understand. Well, there _should_ be some meaningful
ways to deal with these problems, I don't think Harbour
is such a unique type of software that we'd need to reinvent
everything. For good examples, we can peek into python
and ruby solutions. Problem set is quite similar.
>>> 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 ;)
I don't know if it would be an interesting or rather frustrating
experience, probably both :)
>>> 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? :)
I can just encourage others to join up.
>>> 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 ;)
But the truth is that the world mostly consists
of "moms and dads and sisters". If Linux ever
wants to target them, it'll have to adapt,
packaging hell isn't a good marketing tool ;)
BTW my mom uses OS X :) Everyone else uses Windows,
and luckily, it's not me having to kill off the
trojans from time to time. Which makes me happy also.
> - 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.
Yes, we seem to be fine. I see some room for improvements
in component detection field though.
>>> 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.
Cross-compiling can be put into the mix, I can't remember
ATM how deeply we went into with the last dir layour proposal
sent to this list by Przemek. Anyhow it's something we need
to plan for, it's an important topic. Even on a personal
level: I'd like to eventually drop my Windows VM for good.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
