Re: [gentoo-dev] Re: better support for binary packages

[Philipp Riegger]

Hi Duncan,

I don't see the connection between the email Fabio wrote and your
answer. Do you want to say, that you agree that he's doing what i
described and that it works the way i described it? I doubt it. If you
really care, could you answer my first email and state there the
problems you see with the approach and why you think this is making
Gentoo worse?

On Mon, 2009-05-25 at 11:43 +0000, Duncan wrote:
> Gentoo is in general a from-source metadistribution.  There's limited
> support for binary packages in at least one of the package managers
> (portage), but honestly, that's not what Gentoo's best at, and I don't
> believe that will ever change without making it significantly worse at
> what it IS best at now, the normal from-source Gentoo we know and love.

But how would you make it worse? It already has the functionality to add
repositories for binpackages, why not improve it? Why leave it the way
it is?

> Better to leave the serious distribution level binary repackaging to the
> Gentoo-based distributions like Sabayon.  Let them do what they do best,
> and let Gentoo continue doing what it does best.  By definition, binary
> packaging isn't broken and doesn't need fixed, as that's not part of what
> defines Gentoo, so don't fix what ain't broken! =:^)

Well actually, some time ago Gentoo was by definition running a linux
kernel or a BSD kernel and now it runs in a prefix on Windows and AIX
and Solaris. Some time ago there was some guy called drobbins who was
kind of the leader of Gentoo and now we have a council. If you really
don't want changes, you could stop running emerge --sync.

> That said, I could envision an eselect like "binary profile" switcher,
> that subject to settings in a config file, changes USE flags, CFLAGS, gcc-
> configs an appropriate gcc version, etc, changing PKGDIR appropriately as
> well, so one could easily enough create as many "binary profiles" as
> desired and as the use case dictated.  It's likely various reasonably
> large Gentoo deployments are already doing something like this as it
> could certainly be scripted, but an emergable package to make it easy for
> ordinary joe Gentoo user would be useful, and I believe appreciated by
> many.
>
> (Here, I'd put it to use when testing new gcc versions, making it easy to
> swap out PKGDIRs and revert to the old version either per-package or
> system-wide, if the new version was breaking too much.)
>
> So here:  No to the whole big complicated let's fix Gentoo binaries
> thing.  There's already Gentoo-based binary solutions like Sabayon for
> those so interested, and I can't see Gentoo doing better than they're
> doing, at least not without breaking the from-source that Gentoo's good
> at.  But yes to anyone interested in developing a nice new "binary
> profile" switcher to make managing binary package sets easier for those
> Gentoo admins that would find such a thing useful.  Whether they then
> start making those profiles public and whether anyone else chooses to use
> them is entirely up to the individual admins whose systems would be
> affected.

Not sure, what the binary profile switcher really would change here.
What I was talking about were mostly USE-flags and packages, and I guess
your binary profile switcher doesn't change too much, there.

It would be ok to do all this stuff in an extra project, without Gentoo.
But there are some downsides: You are not Gentoo anymore. The
communication channels get longer and more complicated. In my first post
i described some things that would need to be changed. Either in portage
or in the policy how packages are dealt with. Well, the last is a little
bit impossible outside of Gentoo (I don't want to fork the tree) and I
also don't want to fork portage, so the first is complicated, too.

And all this layer thing Fabio was talking about. I did not try it and I
did not read the code, but I think it makes things much more
complicated. See also the discussion about mixing package managers
between Gentoo and Sabayon. I do not want these problems.

Philipp