Broken KDE Admin Dir

[Malte Starostik]

On Monday 20 January 2003 22:26, Andreas Pour wrote:
> Malte Starostik wrote:
> > > Hmm, you are stating a conclusion without any supporting reasoning :-).
> > >  My query is:  what is the advantage of breaking compilations for
> > > third-party KDE developers?  It certainly is easy enough to add
> > > MIN_CONFIG(3.1) to the 8 kde core package configure.in.in scripts or
> > > whatever, but trying to communicate the need to change something so
> > > obscure to the thousands of independent KDE developers is a lot more
> > > cumbersome, wouldn't you agree?
> >
> > To me this sounds a bit like asking for kdebase HEAD not to rely on any
> > kdelibs features introduced after 3.0. If a developer wants to write a
> > KDE 3.0 app, it seems pretty logical that he is to use a 3.0 admin dir as
> > well, doesn't it?
>
> Hi,
>
> I don't think so, since people will not expect that the newer admin dir
> will have that effect, and you make a huge number of illogical assumptions
> about how people develop in that statement.  For one, I see no way for the
> average person to determine what KDE version an admin dir is from - at
> least I can't tell except I happen to know a few key values in assignment
> changes to check for. For two, I don't know how these admin dirs get passed
> around in general but I do know they end up where they shouldn't - since
> you seem to understand this so well please do explain it to the clueless
> ones like me.

Have a look at 
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kde-common/admin/acinclude.m4.in
I see branch tags there. So you can easily co -rKDE_3_0_BRANCH 
kde-common/admin if you insist on getting it from CVS. IMHO the most logical 
way to get the admin dir for someone who's not developping on the bleeding 
edge would be to use the one from a KDE module in that version. The best 
candidate seems kdesdk, which contains kapptemplate that *installs* and admin 
dir matching the KDE version that kdesdk package comes from. I'm sure 
KDevelop distributes admin/* as well.

> What exacly is your problem with changing it so it works for other people?

No problem, only I don't see that the scenario you describe is a common one.

> > HEAD modules are for HEAD. Always been like that and I don't know why
> > this should change.
>
> B/c nothing I suggest breaks anything for HEAD, it just stops breaking it
> for KDE 3.0.  B/c the admin dir is NOT VERSIONED.  B/c things are breaking.
>  B/c there is no reason not to change it.

It doesn't break things for HEAD, but it adds additional, avoidable, 
maintainance issues: if admin/* doesn't set the required Qt version, the 
modules have to do it themselves. This means more places to do this change 
when the required Qt version changes.
Things are breaking b/c when you use a HEAD admin dir with non-HEAD sources. I 
don't think this is intended use.

-Malte