Mailing List Archive

On Sun, Sep 13, 2009 at 09:45:59PM +0200, Sebastian Pipping wrote:
> Once we have repository-specific atoms we get that for free.
> Maybe we can not make it take ages somehow.

Indeed. Perhaps it is time for the users to start bribing Zac.

--
Alexander Færøy

On Sun, 13 Sep 2009 21:45:59 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:
> Alexander Færøy wrote:
> >> Second issue: "I want foopackage and barpackage, but not your
> >> hacked gcc" Overlays can overshadow tree packages, which can have
> >> undesired effects.
> >
> > Support for overlay information in package.mask?
>
> Once we have repository-specific atoms we get that for free.

Not quite. If both an overlay and the main tree provide foo-1.2,
masking foo-1.2::overlay in Portage would end up masking every foo-1.2.
You also need proper multiple repository support to make it work;
merely adding repo dep specs on top of a pure overlay model isn't
enough.

--
Ciaran McCreesh

On Sun, 13 Sep 2009 21:41:13 +0200, Patrick Lauer <patrick@gentoo.org>
wrote:
> On Sunday 13 September 2009 21:03:13 Jesús Guerrero wrote:
>> On Sun, 13 Sep 2009 20:57:48 +0200, Patrick Lauer <patrick@gentoo.org>
>>
>> wrote:
>> > First issue: How do I find out in which overlay stuff is?
>>
>> http://gentoo.zapto.org/
>
> That's not an official project, not mentioned in the layman docs afaik
> (feel
> free to prove me wrong :) ) and only list the overlays in the layman
> config.
> It's just one step above "fetch from the bugzilla bug" ;)
> (Ok, I'm exaggerating a bit, but it's still very user-unfriendly ...)

I don't know what your point there is. Layman is not official either as
far as I know, and the overlays are unsupported by Gentoo directly.

>> > Second issue: "I want foopackage and barpackage, but not your hacked
>> > gcc"
>> > Overlays can overshadow tree packages, which can have undesired
>> > effects.
>>
>> Smart overlays shouldn't do that (and if you are using ~arch then it's
>> *your* problem).
> How would you avoid it? If I had an overlay I'd dump everything in it
that
> looks remotely interesting to me, and I don't care what you think should
> be in
> my overlay ;)

How? ~arch keywords? And, if you are in ~arch, then you are smart enough
to live with this as well.

>> Yep. All comes down to the same, lack of man power I think.
> Always. And if you ever think you're done some users file some new bugs
:)
> So if you feel unhappy about things go fix them. You have the power!
> (And any excuse that you are not talented enough or whatever ... look,
> they
> let me commit to the tree too!)
>
> Plus there's all the other fronts in the battle for the best linux
distro.
> Bugwrangling, documentation maintenance, security issues, ... there are
> enough
> possibilities even for those that can't or don't want to work on ebuilds

> directly. Just start working on stuff, ask when you need help and it'll
be
> even better soon.
>
> See? It's easy. And you have no excuse not to help. Now just do stuff!
:)

No. It's not me who's unhappy about the current status of things ;)

I already do my work in other areas and I have no more time than I
devote to Gentoo already. I maintain overlays to a minimum, and when
I need an overlay I just pick it and put it into my personal overlay.

Yes, every forum staffer could very well become a developer and spend
their time doing some ebuilding, but then we would have a crappy forum
full of spam (believe me, it takes time to keep it clean) :)
--
Jesús Guerrero

Ciaran McCreesh wrote:
> Not quite. If both an overlay and the main tree provide foo-1.2,
> masking foo-1.2::overlay in Portage would end up masking every foo-1.2.

Why?


> You also need proper multiple repository support to make it work;
> merely adding repo dep specs on top of a pure overlay model isn't
> enough.

Please elaborate on that.



Sebastian

Sebastian Pipping wrote:
> Dale wrote:
>
>> Good question. How would a person know if distrowatch leads people to
>> Gentoo or not? It's not like there is really any way to find out.
>>
>
> - analysing referrer logs
> - doing polls
>
>
>
> sebastian
>
>
>

Where are these referrer logs? I don't recall ever doing one of those.

Hasn't it been said before that Gentoo polls are pretty difficult to do
and not very accurate? Only very few would respond to a poll. Most
would not even know the was going on.


Dale

:-) :-)

On Sun, 13 Sep 2009 16:25:19 -0500, Dale <rdalek1967@gmail.com> wrote:

>
> Where are these referrer logs? I don't recall ever doing one of
> those.
>

They are in the web server logs. Apache includes them in the "combined"
log format, or you can add them in a custom log format.

So cooperation with Infra is required for this sort of analysis.

> Hasn't it been said before that Gentoo polls are pretty difficult to
> do and not very accurate?

I fail to see the difficulty of both creating and filling out a survey
on a forums post.
Also, accuracy is always an issue when doing online surveys as people
can submit it multiple times, and there's always the kids that just
click something out of boredom. Don't think that problem is specific to
Gentoo polls.

Alex

Alex Legler wrote:
> On Sun, 13 Sep 2009 16:25:19 -0500, Dale <rdalek1967@gmail.com> wrote:
>
>
>> Where are these referrer logs? I don't recall ever doing one of
>> those.
>>
>>
>
> They are in the web server logs. Apache includes them in the "combined"
> log format, or you can add them in a custom log format.
>
> So cooperation with Infra is required for this sort of analysis.
>
>
>> Hasn't it been said before that Gentoo polls are pretty difficult to
>> do and not very accurate?
>>
>
> I fail to see the difficulty of both creating and filling out a survey
> on a forums post.
> Also, accuracy is always an issue when doing online surveys as people
> can submit it multiple times, and there's always the kids that just
> click something out of boredom. Don't think that problem is specific to
> Gentoo polls.
>
> Alex
>

As has been said before, a lot of people don't go to the forums to see
the poll. I only go to the forums to search if I have a problem before
posting to the list. There may have been a dozen polls on the forums
and I would have no idea they happened.

Of course, the same could be said about doing a poll on the mailing
lists as well. Some Gentoo users that use the forums may not even know
the mailing lists exists.

I'm not sure any poll could really be accurate no matter which means is
used. Add in the kids you thought of and it just adds more confusion.

Dale

:-) :-)

On Sun, 13 Sep 2009 17:08:38 -0500, Dale <rdalek1967@gmail.com> wrote:

> As has been said before, a lot of people don't go to the forums to see
> the poll. I only go to the forums to search if I have a problem
> before posting to the list. There may have been a dozen polls on the
> forums and I would have no idea they happened.
>

That might be /your personal/ behavior.

> Of course, the same could be said about doing a poll on the mailing
> lists as well. Some Gentoo users that use the forums may not even
> know the mailing lists exists.
>

Do the poll in the Forums. Advertise it on planet, some MLs, maybe the
g.o front page, and on IRC.
That way we reach the users that don't go to the forums, but are on
IRC, and the folks that are on the forums but don't know of the MLs and
vice-versa.

Of course there'll be still people that don't know anything about the
thing, but *shrug*. Those who care, know. And those who don't care,
don't need to know, we have made our effort to reach people.

> I'm not sure any poll could really be accurate no matter which means
> is used.

Maybe that is something we just need to live with. Guess all the other
people who do Internet polls do.

Besides, what can we lose? I don't think Sebastian would mind
preparing and posting the survey. A little more community participation
and a little less time spent talking instead of doing would do us good.

Alex

Alex Legler wrote:
> On Sun, 13 Sep 2009 17:08:38 -0500, Dale <rdalek1967@gmail.com> wrote:
>
>
>> As has been said before, a lot of people don't go to the forums to see
>> the poll. I only go to the forums to search if I have a problem
>> before posting to the list. There may have been a dozen polls on the
>> forums and I would have no idea they happened.
>>
>>
>
> That might be /your personal/ behavior.
>

May be true but someone else mentioned that back when I was going to the
forums. I hadn't thought of it until then.


>
>> Of course, the same could be said about doing a poll on the mailing
>> lists as well. Some Gentoo users that use the forums may not even
>> know the mailing lists exists.
>>
>>
>
> Do the poll in the Forums. Advertise it on planet, some MLs, maybe the
> g.o front page, and on IRC.
> That way we reach the users that don't go to the forums, but are on
> IRC, and the folks that are on the forums but don't know of the MLs and
> vice-versa.
>
> Of course there'll be still people that don't know anything about the
> thing, but *shrug*. Those who care, know. And those who don't care,
> don't need to know, we have made our effort to reach people.
>
>
>> I'm not sure any poll could really be accurate no matter which means
>> is used.
>>
>
> Maybe that is something we just need to live with. Guess all the other
> people who do Internet polls do.
>
> Besides, what can we lose? I don't think Sebastian would mind
> preparing and posting the survey. A little more community participation
> and a little less time spent talking instead of doing would do us good.
>
> Alex
>

I agree that you can only put forth your best effort. I just wouldn't
etch the results in stone. Maybe a pencil would be OK tho.

Dale

:-) :-)

On Sat, 12 Sep 2009 14:15:34 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:

> Ryan Hill wrote:
> > Personally I don't see how gaming the system helps us in any way.
>
> I was afraid it could be read in such a way. Handing out fake version
> numbers would be much easier, wouldn't it? I want every single package
> int he tree to be stable, up to date and polished. But as our resources
> are limited let's focus on packages that are most important first.

That's actually what I meant by gaming the system. We could keep those
particular packages up to the minute, but it wouldn't reflect the state of
our distro as a whole. It's a false metric and I don't see the advantage in
pandering to it. It's much more important that our packages actually work
together than have the highest numbers.

> > Also, screw DW.
>
> I'd be interested to hear details about your attitude off-list.

Sorry, bad way of putting what Jesús later said; we're not in competition.
DistroWatch scores are the least of our worries.


--
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

On Sun, 13 Sep 2009 22:17:19 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:
> Ciaran McCreesh wrote:
> > Not quite. If both an overlay and the main tree provide foo-1.2,
> > masking foo-1.2::overlay in Portage would end up masking every
> > foo-1.2.
>
> Why?

Because an overlay model has only a single foo-1.2. Think of it like
stacks of paper. You've got your main repository:

::gentoo foo-1.1 foo-1.2 foo-1.3

and on top of that you put your overlay:

::extras foo-1.2 foo-1.4
::gentoo foo-1.1 foo-1.2 foo-1.3

and then looking down from the top, all an overlay model package
manager sees is the foo-1.2 from the overlay. There's no
foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
that's made from (gentoo + extras).

There's a different way of looking at it that focuses more on the
repository level view at [1].

[1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/

--
Ciaran McCreesh

Ciaran McCreesh wrote:
> Because an overlay model has only a single foo-1.2. Think of it like
> stacks of paper. You've got your main repository:
>
> ::gentoo foo-1.1 foo-1.2 foo-1.3
>
> and on top of that you put your overlay:
>
> ::extras foo-1.2 foo-1.4
> ::gentoo foo-1.1 foo-1.2 foo-1.3
>
> and then looking down from the top, all an overlay model package
> manager sees is the foo-1.2 from the overlay. There's no
> foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
> that's made from (gentoo + extras).

I see. So it would not work for dependencies but it should work for
masking. That alone wouldn't make me happy, though.


> There's a different way of looking at it that focuses more on the
> repository level view at [1].
>
> [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/

Interesting read. Can you think of anything technical that would make
moving portage to this model impossible?



Sebastian

On Mon, 14 Sep 2009 20:28:26 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:
> Ciaran McCreesh wrote:
> > Because an overlay model has only a single foo-1.2. Think of it like
> > stacks of paper. You've got your main repository:
> >
> > ::gentoo foo-1.1 foo-1.2 foo-1.3
> >
> > and on top of that you put your overlay:
> >
> > ::extras foo-1.2 foo-1.4
> > ::gentoo foo-1.1 foo-1.2 foo-1.3
> >
> > and then looking down from the top, all an overlay model package
> > manager sees is the foo-1.2 from the overlay. There's no
> > foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
> > that's made from (gentoo + extras).
>
> I see. So it would not work for dependencies but it should work for
> masking. That alone wouldn't make me happy, though.

I don't think it would necessarily work for masking either the way
Portage sees it (although iirc it would have done for the way Pkgcore
did things). Masking doesn't make foo-1.2::extras invisible, it just
makes it visible but unusable. Even if you do take the "ignore masked
things entirely" approach, the behaviour's highly weird when things
like repository package.masks become involved -- I'm not sure you could
define a consistent model that does 'the right thing' purely on
overlays (although feel free to try...).

> > There's a different way of looking at it that focuses more on the
> > repository level view at [1].
> >
> > [1]:
> > http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/
>
> Interesting read. Can you think of anything technical that would make
> moving portage to this model impossible?

Other than the usual problems with moving Portage to things? No. The
multiple repository model works fine with Gentoo, and it's possible to
set it up so that it looks to the user exactly like an overlay model
except where ::repo deps are involved.

--
Ciaran McCreesh

Sebastian Pipping wrote:
> Ciaran McCreesh wrote:
>> Because an overlay model has only a single foo-1.2. Think of it like
>> stacks of paper. You've got your main repository:
>>
>> ::gentoo foo-1.1 foo-1.2 foo-1.3
>>
>> and on top of that you put your overlay:
>>
>> ::extras foo-1.2 foo-1.4
>> ::gentoo foo-1.1 foo-1.2 foo-1.3
>>
>> and then looking down from the top, all an overlay model package
>> manager sees is the foo-1.2 from the overlay. There's no
>> foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
>> that's made from (gentoo + extras).
>
> I see. So it would not work for dependencies but it should work for
> masking. That alone wouldn't make me happy, though.
>
>
>> There's a different way of looking at it that focuses more on the
>> repository level view at [1].
>>
>> [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/
>
> Interesting read. Can you think of anything technical that would make
> moving portage to this model impossible?

It shouldn't be too difficult to tweak portage so that multiple
ebuilds of the same version from different repositories are visible
to portage's dependency resolver. Currently, it uses a collection of
3 repositories to resolve dependencies: installed, ebuild, and
binary packages. Replacing the single ebuild repository (portdbapi
class) instance with multiple instances, one for each overlay,
should produce the desired result.
--
Thanks,
Zac

Zac Medico wrote:
> It shouldn't be too difficult to tweak portage so that multiple
> ebuilds of the same version from different repositories are visible
> to portage's dependency resolver. Currently, it uses a collection of
> 3 repositories to resolve dependencies: installed, ebuild, and
> binary packages. Replacing the single ebuild repository (portdbapi
> class) instance with multiple instances, one for each overlay,
> should produce the desired result.

Sounds good. How long do you expect it to take?



Sebastian

Sebastian Pipping wrote:
> Zac Medico wrote:
>> It shouldn't be too difficult to tweak portage so that multiple
>> ebuilds of the same version from different repositories are visible
>> to portage's dependency resolver. Currently, it uses a collection of
>> 3 repositories to resolve dependencies: installed, ebuild, and
>> binary packages. Replacing the single ebuild repository (portdbapi
>> class) instance with multiple instances, one for each overlay,
>> should produce the desired result.
>
> Sounds good. How long do you expect it to take?

Not long. It seems like a reasonably useful feature, so I'll go
ahead and try to get it done sometime during the next few days. Then
I'll be able to include it in the portage-2.1.7 branch which I plan
to create soon. You can track progress on this bug:

http://bugs.gentoo.org/show_bug.cgi?id=262038
--
Thanks,
Zac

Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted:

> Duncan wrote:
>> [L]et's get some context here. layman's no difficulty at all, really,
>> when compared to the ordinary stuff we expect Gentoo users to do all
>> the time.
>
> I think you forget about the learning curve: Gentoo users are not born
> as Gentoo users. They are coming from other distros (say Debian or
> Ubuntu).

Not forgetting that, but perhaps forgetting how "unordinary" my own
experience was. I came from Mandrake, but researched Gentoo well enough
that I was already explaining portage basics based on the material in the
Handbook, etc, on the user list (and reading the dev list), before I even
had Gentoo installed.

I like to think that if I can do it, everybody can, but regardless of
whether they /can/ or not, it's a fact that not everybody /does/, as
demonstrated by the fact that people were asking the questions I was
answering.

I /do/ sometimes forget /that/ end of it, that for whatever reason, not
everybody chooses to read the handbook, etc, even if it's ultimately only
making the job of sysadmining their own Gentoo boxen an order of
magnitude harder than it should be.

> For me it was unmasking that confused me a lot in the beginning. There
> is three different kinds, one is not in "the books" afaik and it's no
> fun to me to do. I guess without autounmask by now I would be so
> frustrated to not use Gentoo anymore.

You have me wondering now what's "not in the books." I'd guess the three
types of masking must be (entirely) unkeyworded, ~arch keyworded, and
hard-masked (package.mask-ed), but again, unless that material has
actually been /removed/ from the handbook since 2004, I was actually
explaining all that to others even from my still Mandrake system, so
it's /certainly/ in the books!

And I don't need for autounmask, tho I do run ~arch. But the thing is,
if people are running enough individual ~arch packages so handling it
manually is difficult enough they need a tool for it, from my viewpoint,
they should seriously consider running ~arch anyway, since stable is
tested, and ~arch is somewhat tested, but nobody much tests a half-and-
half system nor could it be practically so in any case since there's just
too many millions of variants there to test, so trying to run such a half-
and-half system is really asking for more trouble than trying to run a
full ~arch system.

But with a few small refinements over the years as Gentoo and its FLOSS
environment have changed, again, that's very close to the same position
and explanation I took from the very beginning, while I was still working
on my first install.

> Seriously, stuff like the layman setup mess is another tiny reason
> keeping our user base smaller than needed, keeping our recruiting rates
> down.

I guess I just don't see it. There's a reason the packages on the
overlays aren't yet part of the tree, because in general, either the
ebuilds (if not the upstream packages) aren't yet mature enough to be in-
tree (at least unmasked, in-tree), or they're community ebuilds, not
Gentoo-dev vetted ones. Keeping that distinction, for the protection of
both Gentoo and its users, is a deliberate policy. Those who are mature
enough to handle the risks of overlays can get them with little problem,
while those newbies who self-evidently are NOT mature enough in their
Gentoo usage to properly handle the risk (or it'd not be a problem for
them in the first place since they'd be comfortable with the tools and
how to use them), are by deliberate policy, kept away from the additional
risk and danger.

Other than minor refinements here or there, I just don't see how that can
or should be changed, unless we're simply deciding that policy is wrong-
headed, so damn the torpedoes headed for our users, full steam ahead, let
them at them!

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Duncan wrote:
> Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted:
>
>> Duncan wrote:
>>> [L]et's get some context here. layman's no difficulty at all, really,
>>> when compared to the ordinary stuff we expect Gentoo users to do all
>>> the time.
>> I think you forget about the learning curve: Gentoo users are not born
>> as Gentoo users. They are coming from other distros (say Debian or
>> Ubuntu).
>
> Not forgetting that, but perhaps forgetting how "unordinary" my own
> experience was. I came from Mandrake, but researched Gentoo well enough
> that I was already explaining portage basics based on the material in the
> Handbook, etc, on the user list (and reading the dev list), before I even
> had Gentoo installed.

My first distro was also Mandrake. I eventually moved endlessly between
Red Hat (before forking into Fedora) and Mandrake. The reason was the
broken rpm package manager (and repo) which had a peculiar way of naming
library .so names which interfered with my "hand-built" packages.

I found Gentoo when a friend of mine told me there was a distro which
was capable of producing CPU *optimized* code because all the packages
were built from source. At the time (6~7 years ago?), I didn't have idea
such distro could exist but that idea made sense and was left hard-coded
in my head.

That is when I read the *Gentoo philosophy* page (yes, there is people
that reads it) and immediately got in love with it. That was Gentoo's
biggest selling point for me. Then the handbook followed and you can
probably guess the rest of the story.

>
> I like to think that if I can do it, everybody can, but regardless of
> whether they /can/ or not, it's a fact that not everybody /does/, as
> demonstrated by the fact that people were asking the questions I was
> answering.

I think it is not a matter of capable of doing it or not but rather
matching one's needs. It is also a fact that most people *don't get it*
when it comes to the question *why gentoo*.
>
> I /do/ sometimes forget /that/ end of it, that for whatever reason, not
> everybody chooses to read the handbook, etc, even if it's ultimately only
> making the job of sysadmining their own Gentoo boxen an order of
> magnitude harder than it should be.
>
>> For me it was unmasking that confused me a lot in the beginning. There
>> is three different kinds, one is not in "the books" afaik and it's no
>> fun to me to do. I guess without autounmask by now I would be so
>> frustrated to not use Gentoo anymore.

The most confusing stuff for me was to learn all the GNU/Linux basics
that I had as granted while using other distros.

(...)

Just my 2 cents about what mattered to *me* (and still matters) when I
moved to Gentoo.
--
Angelo Arrifano AKA MiKNiX
Gentoo Embedded/OMAP850 Developer
Linwizard Developer
http://www.gentoo.org/~miknix
http://miknix.homelinux.com

On 20:46 Sun 13 Sep , Ryan Hill wrote:
> On Sat, 12 Sep 2009 14:15:34 +0200
> Sebastian Pipping <webmaster@hartwork.org> wrote:
> > Ryan Hill wrote:
> > > Personally I don't see how gaming the system helps us in any way.
> >
> > I was afraid it could be read in such a way. Handing out fake version
> > numbers would be much easier, wouldn't it? I want every single package
> > int he tree to be stable, up to date and polished. But as our resources
> > are limited let's focus on packages that are most important first.
>
> That's actually what I meant by gaming the system. We could keep those
> particular packages up to the minute, but it wouldn't reflect the state of
> our distro as a whole. It's a false metric and I don't see the advantage in
> pandering to it. It's much more important that our packages actually work
> together than have the highest numbers.

At the same time, we also want to ensure that any badly out-of-date
packages on there aren't outliers that reflect poorly on our actual
average status. And frankly, having any way to monitor popular yet
outdated packages is a good thing.

--
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com