[gobolinux-users] Re: Gobohide broken on 126.96.36.199?
lijon at kymatica.com
Fri Aug 12 14:57:27 GMT 2005
On Fri, 12 Aug 2005 11:01:50 -0300
Hisham Muhammad <hisham.hm at gmail.com> wrote:
> > As I see it, the existing Perl-XML-Parser--2.34--i686.tar.bz2 is a
> > "subpackage" to Perl--5.8.6--i686.tar.bz2, and should be known as
> > such. Maybe we could have dirs like Perl--5.8.6--SubPackages/ in the
> > package store?
> As I mentioned above, I see it as a package depending on "Perl ==
> 5.8.6". Like Python modules depend on "Python >= 2.3, < 2.4" (but
> still work through point releases).
> > As long as all those details are available somehow, at least in the
> > package itself (in a textfile) or even better extractable trough the
> > net so the user can now if it's worth downloading the binary package
> > or if she should go for the source tarball directly!
> Yes, this is the key. This dependency information should be available
> before the user downloads. Right now the only information the user has
> is what's on the file name, and that's insufficient.
Yes, fair enough. As long as I easily can know in beforehand if I should
download the latest Perl package too, or download the source instead,
> > But that won't work with stuff like D-Bus, which has extensions for
> > a lot of languages... There is also the situation were a package can
> > be built with many different configure enable/disable options, Qt
> > support or not? etc...
> I think package customization is a similar but different issue. For
> binaries, then yes, it's roughly the same problem -- knowing the deps
> of a package beforehand.
And the configuration setup that was used for a binary package! It could
simply be "official practice" to tell in the Description (which should
be available online outside the package) if the package was built with
or without Qt bindings, etc...
> For recipes it gets a bit trickier, but I'm
> hopeful we can pull it off without littering the recipes with if's.
I'd say we put the enable-*/disable-* options in an array which would be
presented to the user (if the proper cmdline argument to Compile was
given) as a simple list of toggles. Either ncurses or CLI style (with
commands like: list, set, clear, save-options, load-options, etc...)
They would have default values (decided by the recipe author) initially.
/Jonatan -=( http://kymatica.com )=-
More information about the gobolinux-users