[gentoo-dev] monolithic automake ebuilds?

[gentoo-dev] monolithic automake ebuilds?

[Evan Powers]

I'm curious, is there a reason the current automake ebuilds bundle several 
automake versions in one big clump rather than having several ebuilds using 
different SLOTs?

I'm aware that automake has undergone a number of incompatible changes since 
1.5, and that a machine will almost certainly want several different automake 
versions installed. But this situation seems to be exactly the problem SLOTs 
were designed to solve.

Is there a reason it's not being done that way?

Evan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] monolithic automake ebuilds?

[Alain]

I don't know what the original reason was, but having them in different SLOTs
would require everyone who writes an ebuild for an app that uses automake
to know which version of automake it uses, and DEPEND on that automake.  I
don't think that's very realistic.

Alain


On Mon, Jan 27, 2003 at 09:02:20PM -0500, Evan Powers wrote:
> I'm curious, is there a reason the current automake ebuilds bundle several 
> automake versions in one big clump rather than having several ebuilds using 
> different SLOTs?
> 
> I'm aware that automake has undergone a number of incompatible changes since 
> 1.5, and that a machine will almost certainly want several different automake 
> versions installed. But this situation seems to be exactly the problem SLOTs 
> were designed to solve.
> 
> Is there a reason it's not being done that way?
> 
> Evan
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] monolithic automake ebuilds?

[Evan Powers]

On Tuesday 28 January 2003 09:05 am, Alain wrote:
> I don't know what the original reason was, but having them in different
> SLOTs would require everyone who writes an ebuild for an app that uses
> automake to know which version of automake it uses, and DEPEND on that
> automake.  I don't think that's very realistic.

Besides laziness, I mean.

And I'd imagine there isn't a single package which DEPENDs on automake in the 
sense that "automake is required to build this package from the distribution 
tarball". Every package source tarball I'm aware of includes pre-generated 
Makefile.in's for exactly the same reason people include pre-generated Yacc 
parsers. If you can unpack && ./configure && make, then you don't have to run 
automake to build the package.

CVS-snapshot ebuilds probably have to run automake, but the Makefile.am's in 
each software package will probably refer to the automake binary as 
automake-x.y, since that's what you're supposed to do since 1.5. I'm not so 
sure it isn't a very good idea to make that dependence explicit, even if it 
is a lot of work. And there can't be all that many CVS ebuilds.

Evan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] monolithic automake ebuilds?

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 28 January 2003 20:16, Evan Powers wrote:
> Besides laziness, I mean.
> 
> And I'd imagine there isn't a single package which DEPENDs on automake in 
the 
> sense that "automake is required to build this package from the distribution 
> tarball". Every package source tarball I'm aware of includes pre-generated 
> Makefile.in's for exactly the same reason people include pre-generated Yacc 
> parsers. If you can unpack && ./configure && make, then you don't have to 
run 
> automake to build the package.
> 
> CVS-snapshot ebuilds probably have to run automake, but the Makefile.am's in 
> each software package will probably refer to the automake binary as 
> automake-x.y, since that's what you're supposed to do since 1.5. I'm not so 
> sure it isn't a very good idea to make that dependence explicit, even if it 
> is a lot of work. And there can't be all that many CVS ebuilds.

Well it's not only cvs ebuilds. Fex. sometimes I find myself wanting to change 
something in a Makefile.am or similar file, which requires a rerun of 
autotools. It's a more common situation (when packaging stuff in ebuilds) 
than you might think and having the autools stuff well automated (e.g. all 
versions are always present and the right one is automagically called) is a 
very good thing to have.

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+N9zPUI2RQ41fiVERAk38AJ4hGyBtntyQo5d9zNF1oI/AzQhn1ACfZMED
dE74IdXKYm5OR74yhfanzFs=
=OBWj
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] monolithic automake ebuilds?

[Martin Schlemmer]

On Mon, 27 Jan 2003 21:02:20 -0500
Evan Powers <powers.161@osu.edu> wrote:

> I'm curious, is there a reason the current automake ebuilds bundle
> several automake versions in one big clump rather than having several
> ebuilds using different SLOTs?
> 
> I'm aware that automake has undergone a number of incompatible changes
> since 1.5, and that a machine will almost certainly want several
> different automake versions installed. But this situation seems to be
> exactly the problem SLOTs were designed to solve.
> 
> Is there a reason it's not being done that way?
> 

Because it simplifies dependencies, and auto detection of what version
should be used ?


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


--
gentoo-dev@gentoo.org mailing list