* Paul de Vrieze <[EMAIL PROTECTED]> schrieb:
<snip>
> > I just want to keep things simple. We're talking about introducing
> > new (additional) logic. This has to be maintained. And it doesn't
> > actually *solve* the problem which is this discussion was started.
>
> Removing the stuff from the ebuild and maintaining two ebuilds that
> must be synchronized with eachother is complex.
Where exactly have the two packages gtk1 and gtk2 to be synchonized ?
<snip>
> > Rember: we started with the thesis, "grandma wants graphical
> > frontends whereever possible". This is in fact not an technical
> > issue, instead a matter of personal taste, or lets say, an individual
> > system configuration. Grandma wants to click, okay, so she should
> > use graphical applications. She's not interested what sits behind,
> > she just wants to have a buch of applications. And she also doesn't
> > wann have anything to do with emerge and useflags. She just wants
> > to have a choice between a bunch of end-user applications.
> > That's the job of an Grandma-(sub-)distro.
>
> gentoo is not a grandma distro and does not try to be so.
No, it is not, and it shall not.
But this was example at the start of this whole discussion.
I understand the intentions to make such things easier,
but I really doubt it will be an *real* solution.
If you see it as a huge set of possible system configurations
(defined by list of installed packages, versions, useflags, ...),
each individual configuration as an element of this set, then our
Grandma-scenario is an subset: we cut out a bunch of elements
which may be interesting for the intended audience.
So in other words: we need some kind of preselection.
Default useflags and useflag aliases on profile basis.
Maybe there could be an extra file, ie. package.use.alias
foo/bar gui=gtk
blah/blubb gui=qt2
...
I'm not sure if this alias handling should be done by emerge,
or better by some frontend (I learned that explicit downgrade
warnings should be done by an frontend, so why should useflag
aliasing shouldn't ?). But I'm sure these information should
not go directly to the ebuilds.
<snip>
> > Okay, let's say we want to intruduce an meta-useflag for "GUI"
> > (although having additional GUIs in the same package as the
> > backend isn't what I consider clean design). If there's just *one*
> > than it's easy - just an alias. But what's if we have more ?
> > Who makes the decision, which one to take ? Based on what rules ?
>
> The council makes the decisions.
How detailed is this decision ?
Global for all or by package ?
<snip>
> > Yes. For optional features. Additional programs aren't features of
> > some other program, but additional programs.
>
> You should read up on your history. Useflags are as well for additional
> programs as for features. This is especially true when things should
> be kept together as they are tightly coupled.
This soon gets confusing for many people. See the dhcp thread.
There're lots of discussions about the server and client useflags.
Could have been done easily by splitting off into two packages,
one for server, one for client and providing an meta package for
people who like to have both.
<snip>
> > I consider it *very* clean. What could be easier than have an
> > consistent database which *knows* what's installed on the system
> > instead of having to run lots of esoteric tests which shall *guess*
> > it somehow ?!
>
> The tests don't actually guess.
Really ?
In the recent years I had do lots of fixes in many autoconf stuff
(autotools itself as well as configure.ac's) to get them working
on situations where building and target systems aren't the same.
Obviously this is not the case for gentoo (it's an self-building
distro, not system A building for an completely different system B),
so you probably don't get involved in such problems.
For example, if you're building in an sysroot'ed environment, you
have tweak patches - "/" mostly doesn't mean the running systems's
root, but the target system image.
Many packages provide their own autoconf macros for detecting if
the package is installed. In 99% they don't provide more information
than can be found in an .pc file. But they introduce additional
complexity, could have been nailed down by an simple pkg-config
query. You don't even need autoconf for that - can also directly
be done within an makefile. But if each package provides its own
implementation, they all have to be tweaked by their own for such
non-stardard situations. When using pkg-config, there's only
one central point to intercept.
If you regenerate the configure stuff of some package A which *may*
require some package B (if the appropriate feature is selected),
you will need to have the package B installed, so the macros can
be found. Not because it will be actually required, but just for
getting the configure script built. Okay, some packages ship a
copy of the macros by their own, but this again is additional
complexity: the package developers have to keep it up-to-date.
<snip>
> The main problem though is that pkg-config encourages wrong linking.
No, it doesn't encourage it. Maybe it takes some presure to do so.
But the individual autoconf macros do the same.
BTW: there are scenarios, where such dependency information within
the shared objects are not feasible. For example, if you don't
*want* to have strict dependency graphs, instead several shared
objects making up an (virtual) library. Most of these cases could
be circumvented by very clean and strict design from gound up.
C is not Oberon. C allows such non-strict linking, like it or not.
If you really want to *encourage* this strictness, there are far
better concepts, you could go in an direction like
http://wiki.metux.de/public/TreeBuild
and get rid off much, much complexits immediately.
But I had to learn, it's not the question what *could* be done,
instead what's *actually* done. People don't seem to like those
approaches very much. I tried to port many packages to treebuild,
but just me alone isn't far enough manpower for that.
So I tried to get some steps back and repair packages to at least
go away from individual macros.
BTW: you didn't answer how you wanna get the dependencies solved
with static archives or on platforms which don't provide these
dependency information. Maybe I'm not up-to-date, but I didn't
ever see dll dependencies on win32.
> > If necessary, this database query can be intercepted easily. With
> > the esoteric testing its very complicated or at least work intensive.
>
> There is nothing esoteric about checking for the existence of libfoo.
You miss the question of installation pathes. Any you miss the
dozens of --with-libfoo=... options.
Obviously there's a strong interest that certain libraries can be
installed in specific locations (ie. for MVCC, etc) and client
packages need to find them.
BTW: an pkg-config query is much, much faster than building a whole
hello-world just for checking if some package is there.
And another scenario for pkg-config: packages are not necessarily
equal with (shared) libraries. For example the -proto packages
of Xorg. How do you intend to handle that ?
<snip>
> > Well, how would you get certain search pathes (-I, -L, ...)
> > additional includes, dependency info for evrything but elf-so, ie .a ?
>
> The thing is you don't should not link the dependent libs of a dependency.
> That way you don't need to recompile if (say gtk was compiled with a new
> libpng version)
Yes, of course. Such double-dependencies are bad. But it's not an
pkg-config issue. If people write bad .pc files, you really can't
blame pkg-config for that. It has proper dependency handling.
Again, you missed to answer my question: how to you intend to
handle non-default search pathes ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@gentoo.org mailing list
