FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-23-2012, 04:47 PM
Justin
 
Default RFC: PROPERTIES=funky-slots

On 23.06.2012 18:17, Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 18:13:23 +0200
> Justin <jlec@gentoo.org> wrote:
>> Did you read what you wrote and thought about what you request from
>> others? Probably you better should.
>
> Uh huh, and I think we all know there's a huge difference between
> knowing what versions and slots are and knowing what "a multilib" is.
>

Might be right, but that doesn't allow you to break your own rules.
Plus I still don't get the problem of using SLOTS in the way they are
used now.

And I can't find this out by simply googling. In contrast, an
explanation of multilib in context of linux distribution and more
specific gentoo can be found easily.
But that's nothing I wanted to discuss here.

Stop acting in this arrogant way you are doing right now. This doesn't
make sympathetic in any way and heavily overshadows the technically
skills you will have for sure.

>> An example:
>>
>> "...slots and versions to "mean" something other than what they used
>> to,..."
>>
>> is completely useless without a description of what SLOTS are about
>> and how the should be used. And what is the wrong usage you can find;
>> examples are necessary here for understanding.
>
> That's covered in the devmanual and in the user documentation, so
> there's no need to repeat it here.

Ever heard about references. They are good, if you don't like to repeat
what is written, but which are necessary context to understand what you
are writing. You should use them for the sake of understanding, if you
are to lazy to write it out again.

>
>> To me, it doesn't solve the root cause, but actually I can't judge
>> this, because I am missing a description of what is really going
>> wrong.
>
> As I've already said, this isn't about solving the root cause. It's
> about reducing the impact of damage that's already been done until the
> root cause is solved properly.
>

My clear vote is No. We shouldn't implement anything which allows bad
coding anywhere, just for the sake of having it "solved" now.
 
Old 06-23-2012, 04:53 PM
Ciaran McCreesh
 
Default RFC: PROPERTIES=funky-slots

On Sat, 23 Jun 2012 18:47:26 +0200
Justin <jlec@gentoo.org> wrote:
> On 23.06.2012 18:17, Ciaran McCreesh wrote:
> > On Sat, 23 Jun 2012 18:13:23 +0200
> > Justin <jlec@gentoo.org> wrote:
> >> Did you read what you wrote and thought about what you request from
> >> others? Probably you better should.
> >
> > Uh huh, and I think we all know there's a huge difference between
> > knowing what versions and slots are and knowing what "a multilib"
> > is.
> >
>
> Might be right, but that doesn't allow you to break your own rules.
> Plus I still don't get the problem of using SLOTS in the way they are
> used now.

"My own rules" are that enough material is presented that the relevant
people understand it. If you look at simple proposals like usex, silent
rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
very little in the way of text in cases where the change is easily
understood.

> And I can't find this out by simply googling. In contrast, an
> explanation of multilib in context of linux distribution and more
> specific gentoo can be found easily.

Oh really? I was under the impression that there wasn't even general
agreement upon whether or not multilib applied to "C" or to "C, and
Python, and things like it".

> Stop acting in this arrogant way you are doing right now.

Come on. Submitting a simple proposal with at least as much detail as
was provided for other, equally simple proposals is "arrogant" now?

> > That's covered in the devmanual and in the user documentation, so
> > there's no need to repeat it here.
>
> Ever heard about references. They are good, if you don't like to
> repeat what is written, but which are necessary context to understand
> what you are writing. You should use them for the sake of
> understanding, if you are to lazy to write it out again.

Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
it references what "phase functions" are, or the proposal for usex and
say where it references what "use flags" are, or the proposal for
silent rules where it references what "econf" is.

> >> To me, it doesn't solve the root cause, but actually I can't judge
> >> this, because I am missing a description of what is really going
> >> wrong.
> >
> > As I've already said, this isn't about solving the root cause. It's
> > about reducing the impact of damage that's already been done until
> > the root cause is solved properly.
>
> My clear vote is No. We shouldn't implement anything which allows bad
> coding anywhere, just for the sake of having it "solved" now.

The bad coding has already happened. Are you volunteering to revert the
Ruby virtuals?

--
Ciaran McCreesh
 
Old 06-23-2012, 05:14 PM
Justin
 
Default RFC: PROPERTIES=funky-slots

On 23.06.2012 18:53, Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 18:47:26 +0200
> Justin <jlec@gentoo.org> wrote:
>> On 23.06.2012 18:17, Ciaran McCreesh wrote:
>>> On Sat, 23 Jun 2012 18:13:23 +0200
>>> Justin <jlec@gentoo.org> wrote:
>>>> Did you read what you wrote and thought about what you request from
>>>> others? Probably you better should.
>>>
>>> Uh huh, and I think we all know there's a huge difference between
>>> knowing what versions and slots are and knowing what "a multilib"
>>> is.
>>>
>>
>> Might be right, but that doesn't allow you to break your own rules.
>> Plus I still don't get the problem of using SLOTS in the way they are
>> used now.
>
> "My own rules" are that enough material is presented that the relevant
> people understand it. If you look at simple proposals like usex, silent
> rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
> very little in the way of text in cases where the change is easily
> understood.
>
>> And I can't find this out by simply googling. In contrast, an
>> explanation of multilib in context of linux distribution and more
>> specific gentoo can be found easily.
>
> Oh really? I was under the impression that there wasn't even general
> agreement upon whether or not multilib applied to "C" or to "C, and
> Python, and things like it".
>
>> Stop acting in this arrogant way you are doing right now.
>
> Come on. Submitting a simple proposal with at least as much detail as
> was provided for other, equally simple proposals is "arrogant" now?
>
>>> That's covered in the devmanual and in the user documentation, so
>>> there's no need to repeat it here.
>>
>> Ever heard about references. They are good, if you don't like to
>> repeat what is written, but which are necessary context to understand
>> what you are writing. You should use them for the sake of
>> understanding, if you are to lazy to write it out again.
>
> Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
> it references what "phase functions" are, or the proposal for usex and
> say where it references what "use flags" are, or the proposal for
> silent rules where it references what "econf" is.
>
>>>> To me, it doesn't solve the root cause, but actually I can't judge
>>>> this, because I am missing a description of what is really going
>>>> wrong.
>>>
>>> As I've already said, this isn't about solving the root cause. It's
>>> about reducing the impact of damage that's already been done until
>>> the root cause is solved properly.
>>
>> My clear vote is No. We shouldn't implement anything which allows bad
>> coding anywhere, just for the sake of having it "solved" now.
>
> The bad coding has already happened. Are you volunteering to revert the
> Ruby virtuals?
>


I give up. And actually I don't care anymore.

When I saw the first people leaving this project, because of all this
non social bitching, I thought by myself, this will never happen to me.
But the amount of fruitful discussion here is so less compared to the
shire amount crap coming through, that it is not worth following it.

justin
 
Old 06-23-2012, 05:16 PM
Alec Warner
 
Default RFC: PROPERTIES=funky-slots

On Sat, Jun 23, 2012 at 9:17 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 18:13:23 +0200
> Justin <jlec@gentoo.org> wrote:
>> Did you read what you wrote and thought about what you request from
>> others? Probably you better should.
>
> Uh huh, and I think we all know there's a huge difference between
> knowing what versions and slots are and knowing what "a multilib" is.
>
>> An example:
>>
>> "...slots and versions to "mean" something other than what they used
>> to,..."
>>
>> is completely useless without a description of what SLOTS are about
>> and how the should be used. And what is the wrong usage you can find;
>> examples are necessary here for understanding.
>
> That's covered in the devmanual and in the user documentation, so
> there's no need to repeat it here.

http://devmanual.gentoo.org/general-concepts/slotting/index.html
http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies

I don't think the documentation forbids what these developers are
doing. I think you implemented a nice heuristic for your users in your
resolver that used to work because slots had a typical set of users
cases and the heuristic performed well in those cases.

Now people are occasionally using slots in a different way and your
heuristic penalizes those cases. That sucks, but you might have to
actually change your resolver because I don't think 'funky-slots'
properties is going to garner much adoption. It just appears that the
heuristic you used to use isn't helpful anymore (or has too any false
positives, or whatever.)

-A

>
>> To me, it doesn't solve the root cause, but actually I can't judge
>> this, because I am missing a description of what is really going
>> wrong.
>
> As I've already said, this isn't about solving the root cause. It's
> about reducing the impact of damage that's already been done until the
> root cause is solved properly.
>
> --
> Ciaran McCreesh
 
Old 06-23-2012, 05:23 PM
Pacho Ramos
 
Default RFC: PROPERTIES=funky-slots

El sáb, 23-06-2012 a las 17:53 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 18:47:26 +0200
> Justin <jlec@gentoo.org> wrote:
> > On 23.06.2012 18:17, Ciaran McCreesh wrote:
> > > On Sat, 23 Jun 2012 18:13:23 +0200
> > > Justin <jlec@gentoo.org> wrote:
> > >> Did you read what you wrote and thought about what you request from
> > >> others? Probably you better should.
> > >
> > > Uh huh, and I think we all know there's a huge difference between
> > > knowing what versions and slots are and knowing what "a multilib"
> > > is.
> > >
> >
> > Might be right, but that doesn't allow you to break your own rules.
> > Plus I still don't get the problem of using SLOTS in the way they are
> > used now.
>
> "My own rules" are that enough material is presented that the relevant
> people understand it. If you look at simple proposals like usex, silent
> rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
> very little in the way of text in cases where the change is easily
> understood.
>
> > And I can't find this out by simply googling. In contrast, an
> > explanation of multilib in context of linux distribution and more
> > specific gentoo can be found easily.
>
> Oh really? I was under the impression that there wasn't even general
> agreement upon whether or not multilib applied to "C" or to "C, and
> Python, and things like it".
>
> > Stop acting in this arrogant way you are doing right now.
>
> Come on. Submitting a simple proposal with at least as much detail as
> was provided for other, equally simple proposals is "arrogant" now?

Did you send this proposal seriously or only to troll comparing it with
what you think tommy did with multilib thread?

If this is seriously, could you explain more how paludis behave in this
case? Looks like it treats SLOT with major number as latest version,
that is not always true and I don't understand why it should be always
true as there are cases where upstream could release newer 3.0.x
releases that are really newer than 3.1.x versions.

Current -r300/200 stuff shouldn't break as it's only used to slot
libraries and that libs will only be installed when some app RDEPENDs on
them.

>
> > > That's covered in the devmanual and in the user documentation, so
> > > there's no need to repeat it here.
> >
> > Ever heard about references. They are good, if you don't like to
> > repeat what is written, but which are necessary context to understand
> > what you are writing. You should use them for the sake of
> > understanding, if you are to lazy to write it out again.
>
> Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
> it references what "phase functions" are, or the proposal for usex and
> say where it references what "use flags" are, or the proposal for
> silent rules where it references what "econf" is.
>
> > >> To me, it doesn't solve the root cause, but actually I can't judge
> > >> this, because I am missing a description of what is really going
> > >> wrong.
> > >
> > > As I've already said, this isn't about solving the root cause. It's
> > > about reducing the impact of damage that's already been done until
> > > the root cause is solved properly.
> >
> > My clear vote is No. We shouldn't implement anything which allows bad
> > coding anywhere, just for the sake of having it "solved" now.
>
> The bad coding has already happened. Are you volunteering to revert the
> Ruby virtuals?
>
 
Old 06-23-2012, 05:24 PM
Ciaran McCreesh
 
Default RFC: PROPERTIES=funky-slots

On Sat, 23 Jun 2012 10:16:42 -0700
Alec Warner <antarus@gentoo.org> wrote:
> I don't think the documentation forbids what these developers are
> doing.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

"This means that counting goes as follows: 1.0 (initial version),
1.0-r1, 1.0-r2, etc."

It's not illegal, but it's also not in line with how versions and slots
have interacted up until now.

> I think you implemented a nice heuristic for your users in your
> resolver that used to work because slots had a typical set of users
> cases and the heuristic performed well in those cases.
>
> Now people are occasionally using slots in a different way and your
> heuristic penalizes those cases. That sucks, but you might have to
> actually change your resolver because I don't think 'funky-slots'
> properties is going to garner much adoption.

You mean, instead of implementing trivial marking, which takes
developers a few seconds, you want to screw over users? I think that
says a lot about Gentoo's attitude...

--
Ciaran McCreesh
 
Old 06-23-2012, 05:30 PM
Ciaran McCreesh
 
Default RFC: PROPERTIES=funky-slots

On Sat, 23 Jun 2012 19:23:57 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Did you send this proposal seriously or only to troll comparing it
> with what you think tommy did with multilib thread?

Uhm, this proposal is exactly in line with dozens of others that have
been made for EAPI 5. It's simple, low impact and easy to understand.
Please explain for everyone's benefit how you think this proposal is in
any way different to the EBUILD_PHASE_FUNC proposal, or the usex
proposal, or the silent rules proposal.

> If this is seriously, could you explain more how paludis behave in
> this case? Looks like it treats SLOT with major number as latest
> version, that is not always true and I don't understand why it should
> be always true as there are cases where upstream could release newer
> 3.0.x releases that are really newer than 3.1.x versions.

It treats -r300 as being newer than -r200, and so will treat "the gtk3
version" or "the jruby version" as being newer versions of "the gtk2
version" or "the ruby 1.8 version", just as it tries to bring in a
newer GCC and so on.

--
Ciaran McCreesh
 
Old 06-23-2012, 05:34 PM
Kent Fredric
 
Default RFC: PROPERTIES=funky-slots

On 24 June 2012 05:16, Alec Warner <antarus@gentoo.org> wrote:
>>
>> That's covered in the devmanual and in the user documentation, so
>> there's no need to repeat it here.
>
> http://devmanual.gentoo.org/general-concepts/slotting/index.html
> http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies
>
> I don't think the documentation forbids what these developers are
> doing. I think you implemented a nice heuristic for your users in your
> resolver that used to work because slots had a typical set of users
> cases and the heuristic performed well in those cases.
>
> Now people are occasionally using slots in a different way and your
> heuristic penalizes those cases. That sucks, but you might have to
> actually change your resolver because I don't think 'funky-slots'
> properties is going to garner much adoption. It just appears that the
> heuristic you used to use isn't helpful anymore (or has too any false
> positives, or whatever.)
>


It seems to me that the defacto understanding of slots is that given 2
slots for one package, one slot will be a natural upgrade from another
competing slot, assuming a slot that is a version progression.

This makes sense for most packages.

However, it seems slots are in some cases being used for purposes
other than natural version progressions, and representing siblings
instead of child/parent , and in such case, its not logical to want to
install a different sibling simply for having a different sibling
installed.

So the request is to have some sort of metadata to optionally convey
the intent of what the slot "means", where the defacto method would be
"They're versions, if X > Y then X is a natural upgrade from Y, and
is slotted for transition and similar reasons" , which would indicate
to UA's that if they have Y, and X becomes available, that they will
want to install X.

And there would be the alternative(s), "Funky slots" , where slots
DONT indicate version progression, and so should *not* be 'upgraded'
to from alternative slots.

Logical place to store such information to me seems <metadata.xml>


--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 
Old 06-23-2012, 05:35 PM
Alec Warner
 
Default RFC: PROPERTIES=funky-slots

On Sat, Jun 23, 2012 at 10:24 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 10:16:42 -0700
> Alec Warner <antarus@gentoo.org> wrote:
>> I don't think the documentation forbids what these developers are
>> doing.
>
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>
> "This means that counting goes as follows: 1.0 (initial version),
> 1.0-r1, 1.0-r2, etc."
>
> It's not illegal, but it's also not in line with how versions and slots
> have interacted up until now.

I agree and I sympathize with your position.

>
>> I think you implemented a nice heuristic for your users in your
>> resolver that used to work because slots had a typical set of users
>> cases and the heuristic performed well in those cases.
>>
>> Now people are occasionally using slots in a different way and your
>> heuristic penalizes those cases. That sucks, but you might have to
>> actually change your resolver because I don't think 'funky-slots'
>> properties is going to garner much adoption.
>
> You mean, instead of implementing trivial marking, which takes
> developers a few seconds, you want to screw over users? I think that
> says a lot about Gentoo's attitude...

I don't think portage has the behavior that paludis does, so most
users are not likely to experience this particular problem. You know
as well as I that the marking isn't necessarily trivial. Its another
thing we have to document and train people to use. I don't think users
get 'screwed over' either.

It could be that instead of Gentoo tagging a bunch of ebuilds, you
just change your resolver heuristic a bit.

-A

>
> --
> Ciaran McCreesh
 
Old 06-23-2012, 05:36 PM
Ciaran McCreesh
 
Default RFC: PROPERTIES=funky-slots

On Sat, 23 Jun 2012 10:35:36 -0700
Alec Warner <antarus@gentoo.org> wrote:
> I don't think portage has the behavior that paludis does, so most
> users are not likely to experience this particular problem. You know
> as well as I that the marking isn't necessarily trivial.

But this time it is trivial. That's the point.

> It could be that instead of Gentoo tagging a bunch of ebuilds, you
> just change your resolver heuristic a bit.

The resolver heuristic is correct, except in the cases where people are
doing utterly weird things with revisions and slots.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 06:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org