[gobolinux-users] Re: Gobohide broken on 220.127.116.11?
hisham.hm at gmail.com
Fri Aug 12 14:01:50 GMT 2005
On 8/11/05, Jonatan Liljedahl <lijon at kymatica.com> wrote:
> On Thu, 11 Aug 2005 17:18:05 -0300
> Hisham Muhammad <hisham.hm at gmail.com> wrote:
> > On 8/11/05, Jonatan Liljedahl <lijon at kymatica.com> wrote:
> > > On Thu, 11 Aug 2005 14:15:28 -0300
> > > Hisham Muhammad <hisham.hm at gmail.com> wrote:
> > > > Jonatan Liljedahl <lijon at kymatica.com> wrote:
> > > > > Another similar issue is the names of binary packages compiled
> > > > > for some specific version of another package. Like the
> > > > > Perl-XML-parser which is compiled for Perl 5.8.6 and won't work
> > > > > with other versions unless you rename the version specific
> > > > > dirs... So the package should be named so you know for what Perl
> > > > > version it's compiled.
> > > >
> > > > At first this sounds like a good idea, but OTOH Perl is just a
> > > > "strict dependency" for the package (we don't want to start
> > > > listing dependency versions in package version numbers :) ). What
> > > > we need instead is to be able to specify "Perl == 5.8.6" in the
> > > > dependencies file.
> > >
> > > The problem is
> > > /Programs/Perl-XML-Parser/Current/lib/perl5/site_perl/5.8.6/
> > > IMHO, there could (should) be a Perl-XML-Parser binary package
> > > available for each available Perl binary package.
> > > I think it should be named
> > > Perl-XML-Parser--2.34--5.8.6--i686.tar.bz2 or something...
> > That is, if we want to support (as a distro) multiple versions of
> > Perl. Do we? Maybe we should just make available the latest Perl and
> > have the Perl-XML-Parser package always match it (and indicate a
> > strict dependency, so that when the user upgrades one they will know
> > they have to upgrade the other).
> And the same for Python, Guile, Ruby, GTK, and all other stuff that may
> have separate plugin packages?
> I'm not so sure. There could be reasons for a user not to use the latest
> version of something. There could be an extension that the user needs
> badly and which isn't updated for the latest version of "something"
> There could be other reasons as well... The user should be free to use
> any version.
Of course, but it's also impractical to maintain packages for all
combinations. For example, when Perl-XML-Parser 2.3.5 is released, do
we build it for Perl 5.8.6, 5.8.5, 5.8.4, etc.? I think we should only
keep the latest one, and for special cases the user can build their
own package using the recipe.
> 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
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.
> 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. For recipes it gets a bit trickier, but I'm
hopeful we can pull it off without littering the recipes with if's.
More information about the gobolinux-users