public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Philipp Riegger <lists@anderedomain.de>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev]  Re: better support for binary packages
Date: Tue, 26 May 2009 09:05:03 +0200	[thread overview]
Message-ID: <1243321504.9661.14.camel@hspc30.informatik.uni-stuttgart.de> (raw)
In-Reply-To: <pan.2009.05.25.11.43.54@cox.net>

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




  reply	other threads:[~2009-05-26  7:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-25  9:54 [gentoo-dev] better support for binary packages Philipp Riegger
2009-05-25 10:16 ` lxnay
2009-05-25 11:43   ` [gentoo-dev] " Duncan
2009-05-26  7:05     ` Philipp Riegger [this message]
2009-05-26  8:48       ` Duncan
2009-05-26 11:00         ` Philipp Riegger
2009-05-26 13:29           ` Duncan
2009-05-26  9:27       ` lxnay
2009-05-26 10:41         ` Philipp Riegger
2009-05-26 17:08         ` Ben de Groot
2009-05-26 18:48           ` lxnay
2009-05-26 20:53             ` Ben de Groot
2009-05-25 15:47   ` [gentoo-dev] " Ben de Groot
2009-05-25 16:00     ` lxnay
2009-05-25 17:20       ` Ben de Groot
2009-05-26  7:30 ` Kobboi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1243321504.9661.14.camel@hspc30.informatik.uni-stuttgart.de \
    --to=lists@anderedomain.de \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox