Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Ciaran McCreesh]

On Wed, 29 Jun 2011 02:47:36 -0400
Mike Frysinger  wrote:
> > Both. There's code in Paludis that duplicates a bunch of that stuff
> > simply because I wasn't sure what I could and couldn't rely upon.
> 
> the file should provide the classic e* output funcs that we've all
> grown to love, and are now enshrined in PMS.  it has had other
> functions come and go over the years, but i think things have settled
> on just the output helpers.  was there anything other than the output
> helpers you were interested in ?

I seem to recall duplicating the colours stuff for Eselect too. But the
variable names seem to be different there, and the 'portageq' call
screws around with things, so perhaps by now things have diverged to the
extent that it's easier to just keep similar but different code around.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] removing of autotools from system set

[Mike Frysinger]

now that we have autotools.eclass to ease regenerating of autotools in
ebuilds and people have generally adopted this tree-wide, i'd like to
look at dropping autoconf, automake, and libtool from the system set.

i'll wait for the current stage-breaking issue to get sorted out (/dev
nodes in stage3) before making the commit, but i want to get this out
there asap because i love making Jorge work for it.

i dont think we'll need to add them to packages.build for stage1 as
all the deps should be correct.

any other issues people can think of ?
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

probably not worth getting into
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Wed, Jun 29, 2011 at 02:38, Ciaran McCreesh wrote:
> On Wed, 29 Jun 2011 02:36:05 -0400 Mike Frysinger wrote:
>> On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
>> > On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
>> >> /etc/init.d/functions.sh has existed for the last decade, and was
>> >> long ago decided as the canonical public entry point for scripts
>> >> external to baselayout (as opposed to a path in /sbin/).  it isnt
>> >> going anywhere, and painting it as something in flux at this point
>> >> is disingenuous.
>> >
>> > Is it documented and specified? If not, can it be?
>>
>> the file path ?  or the API that it provides ?
>
> Both. There's code in Paludis that duplicates a bunch of that stuff
> simply because I wasn't sure what I could and couldn't rely upon.

the file should provide the classic e* output funcs that we've all
grown to love, and are now enshrined in PMS.  it has had other
functions come and go over the years, but i think things have settled
on just the output helpers.  was there anything other than the output
helpers you were interested in ?

i'm not sure where this could be documented other than openrc itself.
but if that appeases people, then that should be trivial to take care
of.
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Matt Turner]

On Wed, Jun 29, 2011 at 2:12 AM, Nirbheek Chauhan  wrote:
> On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger  wrote:
>> On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
>>> On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
>>> > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
>>> >> Honestly, I think a better solution would be to provide a convenience
>>> >> function library, independent of OpenRC. Sourcing random internal
>>> >> scripts of a random package is just broken by concept.
>>> >
>>> > except it hasnt been random and has clearly been defined by having
>>> > existed since the beginning of Gentoo
>>>
>>> I have no idea what this is supposed to mean.
>>
>> /etc/init.d/functions.sh has existed for the last decade, and was long ago
>> decided as the canonical public entry point for scripts external to 
>> baselayout
>> (as opposed to a path in /sbin/).  it isnt going anywhere, and painting it as
>> something in flux at this point is disingenuous.
>
> So... Gentoo's base system can never change, and hence new init
> systems are not welcome. Okay. Got it.

What is this I don't even...

Let's try this again:

Michał said "Sourcing random internal scripts of a random package is
just broken by concept."

Mike then said "except it hasnt been random and has clearly been
defined by having existed since the beginning of Gentoo" and then
further explained what he meant.

So... wtf?

Matt

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Ciaran McCreesh]

On Wed, 29 Jun 2011 02:36:05 -0400
Mike Frysinger  wrote:
> On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
> > On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
> >> /etc/init.d/functions.sh has existed for the last decade, and was
> >> long ago decided as the canonical public entry point for scripts
> >> external to baselayout (as opposed to a path in /sbin/).  it isnt
> >> going anywhere, and painting it as something in flux at this point
> >> is disingenuous.
> >
> > Is it documented and specified? If not, can it be?
> 
> the file path ?  or the API that it provides ?

Both. There's code in Paludis that duplicates a bunch of that stuff
simply because I wasn't sure what I could and couldn't rely upon.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

2011/6/28 Olivier Crête:
> As long as we have Gentoo-style init scripts in the tree, we will need
> these functions to be available. So yes, they should probably be in a
> separate package from openrc itself to ease the transition to the bright
> systemd future.

systemd is limited (acknowledged by its author and encoded in its
basic design) in what it supports.  the set of systems that openrc
supports is significantly larger and simpler (by design).  i really
cant see it being replaced by systemd.
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote:
> On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote:
>> /etc/init.d/functions.sh has existed for the last decade, and was
>> long ago decided as the canonical public entry point for scripts
>> external to baselayout (as opposed to a path in /sbin/).  it isnt
>> going anywhere, and painting it as something in flux at this point is
>> disingenuous.
>
> Is it documented and specified? If not, can it be?

the file path ?  or the API that it provides ?
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Wed, Jun 29, 2011 at 02:12, Nirbheek Chauhan wrote:
> On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger wrote:
>> On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
>>> On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
>>> > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
>>> >> Honestly, I think a better solution would be to provide a convenience
>>> >> function library, independent of OpenRC. Sourcing random internal
>>> >> scripts of a random package is just broken by concept.
>>> >
>>> > except it hasnt been random and has clearly been defined by having
>>> > existed since the beginning of Gentoo
>>>
>>> I have no idea what this is supposed to mean.
>>
>> /etc/init.d/functions.sh has existed for the last decade, and was long ago
>> decided as the canonical public entry point for scripts external to 
>> baselayout
>> (as opposed to a path in /sbin/).  it isnt going anywhere, and painting it as
>> something in flux at this point is disingenuous.
>
> So... Gentoo's base system can never change, and hence new init
> systems are not welcome. Okay. Got it.

you really should refrain from inserting words into other people's
mouths.  at no point did i ever make this statement.
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Ciaran McCreesh]

On Wed, 29 Jun 2011 02:07:52 -0400
Mike Frysinger  wrote:
> /etc/init.d/functions.sh has existed for the last decade, and was
> long ago decided as the canonical public entry point for scripts
> external to baselayout (as opposed to a path in /sbin/).  it isnt
> going anywhere, and painting it as something in flux at this point is
> disingenuous.

Is it documented and specified? If not, can it be?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Nirbheek Chauhan]

On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger  wrote:
> On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
>> On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
>> > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
>> >> Honestly, I think a better solution would be to provide a convenience
>> >> function library, independent of OpenRC. Sourcing random internal
>> >> scripts of a random package is just broken by concept.
>> >
>> > except it hasnt been random and has clearly been defined by having
>> > existed since the beginning of Gentoo
>>
>> I have no idea what this is supposed to mean.
>
> /etc/init.d/functions.sh has existed for the last decade, and was long ago
> decided as the canonical public entry point for scripts external to baselayout
> (as opposed to a path in /sbin/).  it isnt going anywhere, and painting it as
> something in flux at this point is disingenuous.
>

So... Gentoo's base system can never change, and hence new init
systems are not welcome. Okay. Got it.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote:
> On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote:
> > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
> >> Honestly, I think a better solution would be to provide a convenience
> >> function library, independent of OpenRC. Sourcing random internal
> >> scripts of a random package is just broken by concept.
> > 
> > except it hasnt been random and has clearly been defined by having
> > existed since the beginning of Gentoo
> 
> I have no idea what this is supposed to mean.

/etc/init.d/functions.sh has existed for the last decade, and was long ago 
decided as the canonical public entry point for scripts external to baselayout 
(as opposed to a path in /sbin/).  it isnt going anywhere, and painting it as 
something in flux at this point is disingenuous.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Nirbheek Chauhan]

On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger  wrote:
> On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
>> Honestly, I think a better solution would be to provide a convenience
>> function library, independent of OpenRC. Sourcing random internal
>> scripts of a random package is just broken by concept.
>
> except it hasnt been random and has clearly been defined by having existed
> since the beginning of Gentoo
>

I have no idea what this is supposed to mean.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote:
> Honestly, I think a better solution would be to provide a convenience
> function library, independent of OpenRC. Sourcing random internal
> scripts of a random package is just broken by concept.

except it hasnt been random and has clearly been defined by having existed 
since the beginning of Gentoo

> Say, if OpenRC decided to switch into some kind of internal output
> flow, einfo and friends would stop working for all those external
> scripts.

this idea is pure ridiculousness
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] The Python problem

[Michał Górny]

On Tue, 28 Jun 2011 20:03:34 -0430
"Jesus Rivero (Neurogeek)"  wrote:

> On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman 
> wrote:
> > Hi guys,
> [...]
> > So I know a bunch of people have already looked at it, and I'd like
> > to know: what do you find better about the Ruby approach compared
> > to the Python approach? Is it just the size of python.eclass, or
> > are there a number of other issues?
> 
> Let´s start by agreeing with the complexity of the Python eclass. And
> a heavy change right now, is going to be painful to say the least
> because a great deal of packages have been adapted to work the way the
> eclass works right now.
> 
> [...]
> 
> As I said it already, we could start doing things simpler in the
> current python.eclass and maybe that would attract some devs to help
> out with it, as they find it more comfortable to work with.

I think it would be better to simply start from scratch with
a clean python-2.eclass. Instead of adding new features and another lot
of conditionals for EAPI=4, just make that code a part of new eclass.

And remember, the more complex code is, the more painful it becomes for
things like metadata generation.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Michał Górny]

On Tue, 28 Jun 2011 17:10:42 -0500
William Hubbs  wrote:

> the reason for this email is
> http://bugs.gentoo.org/show_bug.cgi?id=373219 and the bugs that
> currently depend on it. I'm sure there will be more of those.
> 
> The background is that /etc/init.d/functions.sh is a link to
> /lib/rc/functions.sh, which is part of openrc.
> 
> Other init systems, like systemd, are coming along which completely
> replace sysvinit and do not use openrc's init scripts at all. However,
> since things other than init scripts are
> using /etc/init.d/functions.sh, all gentoo users are forced to have
> openrc on their systems whether they use its init scripts or not.
> 
> As you can see in the bug, I am working on creating a
> minimalist version of openrc that can be installed to allow users to
> have access to the functions that are in functions.sh regardless of
> whether or not they are using openrc's init system.
> 
> I'm not convinced that this is the best approach, so any input would
> be greatly appreciated.

Honestly, I think a better solution would be to provide a convenience
function library, independent of OpenRC. Sourcing random internal
scripts of a random package is just broken by concept.

Say, if OpenRC decided to switch into some kind of internal output
flow, einfo and friends would stop working for all those external
scripts.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Mike Frysinger]

On Tuesday, June 28, 2011 15:58:46 Michał Górny wrote:
> On Tue, 28 Jun 2011 15:04:00 -0400 Nathan Phillip Brink wrote:
> > On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
> > > ?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
> > > > On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
> > > > > emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> > > > 
> > > > this is easily dangerous when it comes to packages (and many do)
> > > > that append in the Makefile.  specifying on the command line
> > > > blocks those while passing via env works fine.  i'm not sure it's
> > > > appropriate to provide as an example.
> > > 
> > > Hm, I'm not sure I understand what you are talking about here.
> > > Could you provide example?
> > 
> > I think he's referring to somethine like:
> > 
> > Makefile:
> > CFLAGS += `pkg-config --cflags libxml-2.0`
> > 
> > which would work fine for:
> >   emake
> > 
> > but which would override the pkg-config flags if you do:
> >   emake CFLAGS="${CFLAGS}"
> 
> But is overriding really useful in this particular case? It seems
> rather irrelevant here.

if the Makefile starts off with
CFLAGS = 

and then in subdirs it appends, then yes

or people split up the initial hardcode and latter pkg-config appends as 
Nathan showed, then yes
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] RFC: optinal run time dependencies

[Donnie Berkholz]

On 14:38 Tue 28 Jun , Peter Volkov wrote:
> 1. add a use flag to control runtime dependency
> 2. add elog message into pkg_postinst to notify users that some 
> features depend on installing package A, B, etc.

I've got a suggestion that builds a little bit on what both you and 
Ciaran have said.

The UI could probably be clearer if we added a new dependency type like 
SDEPEND (suggested deps) with USE flags for different features. That 
would enable portage to show things in a special way if it knew about 
SDEPEND. Yet it wouldn't do anything weird that broke backwards 
compatibility or produced strange output from noncompliant PMs (like USE 
flag modifications).

Then PMs would be free to implement their own logic for how to handle 
it. For Portage, I'd like to see a few cases:

1) If a package is installed, assume it's desired, as Ciaran proposed.

2) Add a way to determine whether to install all/none/groups of them, 
   w/ configuration in /etc/portage/package.suggestions/. Probably CPV 
   followed by the setting (all, none, specific groups, or specific 
   CPVs). Add an option similar to --autounmask that would let Portage 
   write to this file.

3) Something like the --take argument and friends that Ciaran mentioned 
   seems reasonable (perhaps --accept-suggestion, w/ a short option to 
   save typing).

Problems? Other thoughts?

-- 
Thanks,
Donnie

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


pgpEUroOHMuW9.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[William Hubbs]

Hi,

On Tue, Jun 28, 2011 at 09:07:12PM -0400, Olivier Crête wrote:
> Hi,
> 
> On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
> > The background is that /etc/init.d/functions.sh is a link to
> > /lib/rc/functions.sh, which is part of openrc.
> > 
> > Other init systems, like systemd, are coming along which completely
> > replace sysvinit and do not use openrc's init scripts at all. However,
> > since things other than init scripts are using /etc/init.d/functions.sh,
> > all gentoo users are forced to have openrc on their systems whether they
> > use its init scripts or not.
> > 
> > As you can see in the bug, I am working on creating a
> > minimalist version of openrc that can be installed to allow users to
> > have access to the functions that are in functions.sh regardless of
> > whether or not they are using openrc's init system.
> > 
> > I'm not convinced that this is the best approach, so any input would be
> > greatly appreciated.
> 
> As long as we have Gentoo-style init scripts in the tree, we will need
> these functions to be available. So yes, they should probably be in a
> separate package from openrc itself to ease the transition to the bright
> systemd future.

I'm not advocating killing openrc; I think that the sysvinit/openrc
system we have is going to be our default init system for some time

It isn't init scripts that I'm worried about. The problem is
that scripts other than init scripts are using the code in
/etc/init.d/functions.sh, so some how that code, or something similar to
it needs to be available on systems so that someone, like yourself, who
is not using openrc, can run "emerge --unmerge sysvinit openrc" and have
a working system. Right now, things like revdep-rebuild and eix will
break if you remove openrc.

For the short term I can see it as a subset of openrc, but ultimately I
think if you aren't using openrc's init system it should not be required
on your system.

Any other thoughts?

William



pgp2KCLgV0LMi.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Olivier Crête]

Hi,

On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
> The background is that /etc/init.d/functions.sh is a link to
> /lib/rc/functions.sh, which is part of openrc.
> 
> Other init systems, like systemd, are coming along which completely
> replace sysvinit and do not use openrc's init scripts at all. However,
> since things other than init scripts are using /etc/init.d/functions.sh,
> all gentoo users are forced to have openrc on their systems whether they
> use its init scripts or not.
> 
> As you can see in the bug, I am working on creating a
> minimalist version of openrc that can be installed to allow users to
> have access to the functions that are in functions.sh regardless of
> whether or not they are using openrc's init system.
> 
> I'm not convinced that this is the best approach, so any input would be
> greatly appreciated.

As long as we have Gentoo-style init scripts in the tree, we will need
these functions to be available. So yes, they should probably be in a
separate package from openrc itself to ease the transition to the bright
systemd future.

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The Python problem

[Jesus Rivero (Neurogeek)]

On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman  wrote:
> Hi guys,
[...]
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?
>
> Cheers,
>
> Dirkjan
>
>

Let´s start by agreeing with the complexity of the Python eclass. And
a heavy change right now, is going to be painful to say the least
because a great deal of packages have been adapted to work the way the
eclass works right now.

I agree with Grobian in what he said about the coding style of the
python.eclass, and would love to see that "fixed". I also agree with
the redundancy of some variables and I think just using PYTHON_DEPEND
should be sufficient to let the PM know what should be done with a
specific package.

With python-updater, well, some time ago Ali Polatel implemented some
approaches to get rid of python-updater, by exporting some variable in
ebuilds that needed to be rebuilt when new python versions were
installed. I dont recall what happened with that, but we could think
of some ways to finally get rid of python-updater.

WRT python3, I too believe it is important to have it stable. Thing
is, for better or worse, upstream have it stable, and py2 and py3 are
going to co-exist for a long time. Thing is, we should really figure
out a way to have it stop messing things up. I believe with a proper
dependency handling in the eclass, we could get this to work.

As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find it more comfortable to work with.

Best regards,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer

[gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[William Hubbs]

All,

the reason for this email is
http://bugs.gentoo.org/show_bug.cgi?id=373219 and the bugs that
currently depend on it. I'm sure there will be more of those.

The background is that /etc/init.d/functions.sh is a link to
/lib/rc/functions.sh, which is part of openrc.

Other init systems, like systemd, are coming along which completely
replace sysvinit and do not use openrc's init scripts at all. However,
since things other than init scripts are using /etc/init.d/functions.sh,
all gentoo users are forced to have openrc on their systems whether they
use its init scripts or not.

As you can see in the bug, I am working on creating a
minimalist version of openrc that can be installed to allow users to
have access to the functions that are in functions.sh regardless of
whether or not they are using openrc's init system.

I'm not convinced that this is the best approach, so any input would be
greatly appreciated.

William


pgp8kHkUnVT18.pgp
Description: PGP signature

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Michał Górny]

On Tue, 28 Jun 2011 15:04:00 -0400
Nathan Phillip Brink  wrote:

> On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
> > ?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
> > > On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
> > > > emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> > > 
> > > this is easily dangerous when it comes to packages (and many do)
> > > that append in the Makefile.  specifying on the command line
> > > blocks those while passing via env works fine.  i'm not sure it's
> > > appropriate to provide as an example.
> > 
> > Hm, I'm not sure I understand what you are talking about here.
> > Could you provide example?
> 
> I think he's referring to somethine like:
> 
> Makefile:
> CFLAGS += `pkg-config --cflags libxml-2.0`
> 
> which would work fine for:
>   emake
> 
> but which would override the pkg-config flags if you do:
>   emake CFLAGS="${CFLAGS}"

But is overriding really useful in this particular case? It seems
rather irrelevant here.

AFAIR you can pass 'emake CFLAGS+=sth' too but not sure about that.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Are tags just sets?

[Maciej Mrozowski]

On Tuesday 28 of June 2011 05:26:29 Brian Harring wrote:
> On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote:
> > Here's a completely different way of doing tags:
> > 
> > First, standardise sets. We probably want to go with a format along the
> > 
> > lines of:
> > eapi = 4
> > description = Monkeys
> > 
> > dev-monkey/howler
> > dev-monkey/spider
> > 
> > >=dev-monkey/spanky-2.0
> > 
> > dev-monkey/squirrel
> > 
> > where eapi has to be on the first line.
> > 
> > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag,
> > monkeys-tag etc.
> 
> This is a bit inverted- tagging is fundamentally pkg specific.  If we
> did as you proposed and I wanted to find out all tags/descriptions for
> a pkg, the PM would have to scan every tags file there.
> 
> Additionally, as others have indicated, it sucks have this data tucked
> away in another chunk of the tree, away from where the package data
> actually is (in cat/pkg/*).
> 
> > Advantages: dead easy to implement, backwards compatible, we need sets
> > anyway.
> > 
> > Disadvantages: doesn't use some horribly convoluted system of XML,
> > wikis and web 2.0.
> 
> Counter proposal; use what you're proposing as a cache.  metadata.xml
> is the proper place for this- we store use.local data there for
> example, and cache the results of it in profiles/use.local.desc.  Via
> this vcs concerns are addressed, data locality is preserved, and
> multiple modes of lookup are sanely supported.
> 
> Roughly, and this is definitely a rough sketch:
> 
> 
>  tag1 tag2 tag2 tag3
>  awesomeness
> 
> 
> From there, jammed into profiles, a master description list in 'tag:
> description' style format.  Identifying the eapi is easy enough- just
> inspect the atom's that wind up in the tags list.  Easy enough.
> 
> Either way... thing everyone admits the current tree format has it's
> flaws; strikes me it's better to fit to the standards/conventions of
> the repo format as it is now.
> 
> 
> ~harring

Of course, nobody said metadata.xml would be the place that's to be 
immediately accessed by search tools. But as a data definition is concerned, 
metadata.xml is the right place for tags, not some obscure 'package.mask'-
style flat file.

Whether this information is to be processed for easier usage - by generating 
flat file with "cat/pkg tag1 tag2 ..." in each line for instance - is 
different story and nice to have probably.

@Ciaran
profiles/package.mask is quite convenient being flat file (although 
package.mask.d seems nicer, different story) as masking/unmasking groups of 
packages (KDE releases come to my mind) is a common use case.
Sure, it would benefit from auto-updating (pkgmove mostly as package.mask 
editing is otherwise closely tied to package removals anyway).

-- 
regards
MM


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Alexis Ballier]

On Tue, 28 Jun 2011 22:24:26 +0400
Peter Volkov  wrote:

> В Втр, 28/06/2011 в 12:23 -0400, Mike Frysinger пишет:
> > On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
> > > emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> > 
> > this is easily dangerous when it comes to packages (and many do)
> > that append in the Makefile.  specifying on the command line blocks
> > those while passing via env works fine.  i'm not sure it's
> > appropriate to provide as an example.
> 
> Hm, I'm not sure I understand what you are talking about here. Could
> you provide example?
> 

if the makefile contains something like CFLAGS+="-DMYFEATURE=1" then
'emake CFLAGS="blah"' overrides it but 'CFLAGS="blah" emake' doesnt.

A.

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Nathan Phillip Brink]

On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
> ?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
> > On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
> > > emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> > 
> > this is easily dangerous when it comes to packages (and many do) that 
> > append 
> > in the Makefile.  specifying on the command line blocks those while passing 
> > via env works fine.  i'm not sure it's appropriate to provide as an example.
> 
> Hm, I'm not sure I understand what you are talking about here. Could you
> provide example?

I think he's referring to somethine like:

Makefile:
CFLAGS += `pkg-config --cflags libxml-2.0`

which would work fine for:
  emake

but which would override the pkg-config flags if you do:
  emake CFLAGS="${CFLAGS}"

-- 
binki


pgpwm9rxY2Hpm.pgp
Description: PGP signature

Re: [gentoo-dev] demanual update

[Mike Frysinger]

On Tuesday, June 28, 2011 12:37:41 justin wrote:
> On 6/28/11 6:23 PM, Mike Frysinger wrote:
> > On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
> >> I think that also a good idea may be to provide an Makefile example,
> >> showing that often sed is unnecessary, and it's enough to do things
> >> like:
> >> 
> >> emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> > 
> > this is easily dangerous when it comes to packages (and many do) that
> > append in the Makefile.  specifying on the command line blocks those
> > while passing via env works fine.  i'm not sure it's appropriate to
> > provide as an example. -mike
> 
> There are cases and cases. You are right with what you said. But cases
> where the makefile appends stuff are not the typical cases where a sed
> is applied. Normally sed is used if upstream hardcodes FLAGS we don't
> want.

and those packages should get patched and the patch sent upstream which means 
the sed+cmdline is still unnecessary.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Peter Volkov]

В Втр, 28/06/2011 в 12:23 -0400, Mike Frysinger пишет:
> On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
> > emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> 
> this is easily dangerous when it comes to packages (and many do) that append 
> in the Makefile.  specifying on the command line blocks those while passing 
> via env works fine.  i'm not sure it's appropriate to provide as an example.

Hm, I'm not sure I understand what you are talking about here. Could you
provide example?

--
Peter.

Re: [gentoo-dev] demanual update

[justin]

On 6/28/11 6:23 PM, Mike Frysinger wrote:
> On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
>> On Tue, 28 Jun 2011 10:16:06 +0400 Peter Volkov wrote:
>>> But still our documentation explicitly suggests ':' for CFLAGS cases
>>> and example allows bash substitution.
>>>
>>> http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building
>>> /index.html see example in "Fixing Compiler Usage" section and text
>>> below:
>>> sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh
>>>
>>> Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
>>> attachment)?
>>
>> I think that also a good idea may be to provide an Makefile example,
>> showing that often sed is unnecessary, and it's enough to do things
>> like:
>>
>> emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...
> 
> this is easily dangerous when it comes to packages (and many do) that append 
> in the Makefile.  specifying on the command line blocks those while passing 
> via env works fine.  i'm not sure it's appropriate to provide as an example.
> -mike

There are cases and cases. You are right with what you said. But cases
where the makefile appends stuff are not the typical cases where a sed
is applied. Normally sed is used if upstream hardcodes FLAGS we don't
want. And there the passing with emake is the appropriate safer way for
a fix.

justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Mike Frysinger]

On Tuesday, June 28, 2011 08:25:50 Peter Volkov wrote:
> +Sometimes a package will not use the user's ${CFLAGS} or
> +${LDFLAGS}.

there are more flag vars than this.  you should use language like:
Sometimes a package will not use the user's build settings (such as CFLAGS or 
LDFLAGS).

> -sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh \
> +sed -i -e "s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}|" build.sh \

probably better to suggest delaying of the expansion in the first place.
sed -i -e "s|cc -O2|$(tc-getCC) \${CFLAGS} \${LDFLAGS}|" build.sh \

also, your example ignores CPPFLAGS
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Mike Frysinger]

On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
> On Tue, 28 Jun 2011 10:16:06 +0400 Peter Volkov wrote:
> > But still our documentation explicitly suggests ':' for CFLAGS cases
> > and example allows bash substitution.
> > 
> > http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building
> > /index.html see example in "Fixing Compiler Usage" section and text
> > below:
> > sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh
> > 
> > Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
> > attachment)?
> 
> I think that also a good idea may be to provide an Makefile example,
> showing that often sed is unnecessary, and it's enough to do things
> like:
> 
> emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"...

this is easily dangerous when it comes to packages (and many do) that append 
in the Makefile.  specifying on the command line blocks those while passing 
via env works fine.  i'm not sure it's appropriate to provide as an example.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] SHA256 and indention in metadata.xml

[Mike Frysinger]

On Tuesday, June 28, 2011 08:02:03 Peter Volkov wrote:
> В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет:
> > On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
> > > On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
> > >> Another question, do we have a rule, how the metadata.xml has to be
> > >> indented? Tabs or n spaces?
> > > 
> > > There's no rule, but we should follow the same rule as ebuilds —
> > > indentation should be with a tab that's displayed as 4 spaces in
> > > editors (no expansion of tabs to spaces).
> > 
> > meh ... let devs do whatever they want
> 
> Why? This looks like perfect case to use standard indentation.
> Personally I'd like indentation to be fixed (and I don't really care
> how).

these files are so small/minor, and now we tread into xml territory which has 
much less standardized indenting and line wrapping rules.  it isnt simply a 
matter of "how much space do i put before an open tag".  i really dont see it 
being a "problem" that needs "solving".
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] ldconfig symlink updates -- do we need that?

[Michał Górny]

On Tue, 28 Jun 2011 17:31:11 +0200
Cyprien Nicolas  wrote:

> On 28/06/11 10:53, Michał Górny wrote:
> > On Tue, 28 Jun 2011 10:48:48 +0200 Michał Górny  
> > wrote:
> 
> I'm a noob in Python, but I disagree with this patch. for two reasons:
> 
> First, the -X option is already available, and controlled by
> makelinks, so why not change the default value of makelinks to False?
> 
> Second, after trying to understand the code, if your proposed patch is
> applied, the makelinks variable become useless. So why not remove it
> completly from the source? Is this variable still needed?
> 
> There is some bunch of code starting at line 222 in the current HEAD,
> which sets makelinks to False upon some conditions, does this need to
> be refactored / removed somehow too?

This patch is just the simplest approach to see if it works as
expected. We'll prepare a better/more consistent patch when the concept
itself is accepted.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Are tags just sets?

[Wyatt Epp]

On Tue, Jun 28, 2011 at 07:53, Peter Volkov  wrote:
> В Пнд, 27/06/2011 в 20:26 -0700, Brian Harring пишет:
>> > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag,
>> > monkeys-tag etc.
>
> I'd like avoid editing multiple files. Much better will be keep tags
> with package.
>

> Also I like metadata.xml proposal since it'll be easy to use
> per-category metadata.xml for all ebuilds to inherit.
>
You weren't planning on doing this all _manually_, were you? ;)  With
proper tool support (or even just a couple quick scripts), the
single/multiple file argument becomes pretty much moot.

Another thing I think should be reiterated is that leveraging sets in
this matter gets us implication and aliasing for free (as long as sets
can be included inside of other sets).  I'm not sure it would be so
easy to accomplish otherwise.

Regards,
Wyatt

Re: [gentoo-dev] ldconfig symlink updates -- do we need that?

[Cyprien Nicolas]

On 28/06/11 10:53, Michał Górny wrote:
> On Tue, 28 Jun 2011 10:48:48 +0200 Michał Górny  
> wrote:

I'm a noob in Python, but I disagree with this patch. for two reasons:

First, the -X option is already available, and controlled by makelinks,
so why not change the default value of makelinks to False?

Second, after trying to understand the code, if your proposed patch is
applied, the makelinks variable become useless. So why not remove it
completly from the source? Is this variable still needed?

There is some bunch of code starting at line 222 in the current HEAD,
which sets makelinks to False upon some conditions, does this need to be
refactored / removed somehow too?

-- 
Cyprien Nicolas (fulax)
Lisp project contributor

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

[Peter Volkov]

Thank you Fabian, Michał. Added note on Makefile and mentioned other
tools as well. Updated patch is in attachment.

--
Peter.
>From 9d24f4bab09be481e70ab04c85f20a246162dc0a Mon Sep 17 00:00:00 2001
From: Peter Volkov 
Date: Tue, 28 Jun 2011 10:05:17 +0400
Subject: [PATCH] Use | as a separator for sed'ing CFLAGS

/, : is a bad idea per thread on gentoo-dev:

http://archives.gentoo.org/gentoo-dev/msg_654cd9daf2548a524c8a09a82b80916f.xml
---
 .../functions/src_compile/building/text.xml|   31 +++
 1 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/ebuild-writing/functions/src_compile/building/text.xml b/ebuild-writing/functions/src_compile/building/text.xml
index 700f0f1..1bc3ec2 100644
--- a/ebuild-writing/functions/src_compile/building/text.xml
+++ b/ebuild-writing/functions/src_compile/building/text.xml
@@ -43,10 +43,24 @@ It is not correct to use the ${CC} variable for this purpose.
 
 
 
-Sometimes a package will not use the user's ${CFLAGS} or ${LDFLAGS}.
-This must be worked around, as sometimes these variables are used for specifying
-critical ABI options. In these cases, the build scripts should be modified (for
-example, with sed) to use ${CFLAGS} or ${LDFLAGS} correctly.
+Sometimes a package will not use the user's ${CFLAGS} or
+${LDFLAGS}. This must be worked around, as sometimes these variables are
+used for specifying critical ABI options. In some cases it's enough to pass
+correct parameters for the emake (check Makefile to see if this is
+possible):
+
+
+
+EAPI="4"
+
+src_compile() {
+	emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}"
+}
+
+
+
+In other cases, the build scripts should be modified (for example, with
+sed) to use ${CFLAGS} or ${LDFLAGS} correctly.
 
 
 
@@ -58,15 +72,18 @@ src_compile() {
 
 # We have a weird build.sh to work with which ignores our
 # compiler preferences. yay!
-sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" build.sh \
+sed -i -e "s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}|" build.sh \
 || die "sed fix failed. Uh-oh..."
 ./build.sh || die "Build failed!"
 }
 
 
 
-When using sed with CFLAGS or LDFLAGS, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using sed with CFLAGS or LDFLAGS, it is not safe to
+use a comma, a colon or a slash as a delimiter. gcc, ld,
+ar, etc... options may contain this characters so sed will fail
+after bash expansion. The recommended character is a vertical bar: '|' (the
+pipe).
 
 
 
-- 
1.7.3.4

Re: [gentoo-dev] SHA256 and indention in metadata.xml

[Peter Volkov]

В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет:
> On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
> > On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
> >> Another question, do we have a rule, how the metadata.xml has to be
> >> indented? Tabs or n spaces?
> >
> > There's no rule, but we should follow the same rule as ebuilds —
> > indentation should be with a tab that's displayed as 4 spaces in
> > editors (no expansion of tabs to spaces).
> 
> meh ... let devs do whatever they want

Why? This looks like perfect case to use standard indentation.
Personally I'd like indentation to be fixed (and I don't really care
how).

--
Peter.

Re: [gentoo-dev] SHA256 and indention in metadata.xml

[Peter Volkov]

В Вск, 26/06/2011 в 17:20 +0200, Maciej Mrozowski пишет:
> I never understood the reason after keeping deps not sorted alphabetically 
> where order doesn't matter - it's like someone purposely made ebuild harder 
> to 
> read - it's counter productive.

Like with perl modules with well written configure.ac I like them to be
sorted in the order there. This way makes easier for me to see if there
is anything redundant in deps or not.

--
Peter.

Re: [gentoo-dev] Are tags just sets?

[Peter Volkov]

В Пнд, 27/06/2011 в 20:26 -0700, Brian Harring пишет:
> > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag,
> > monkeys-tag etc.

I'd like avoid editing multiple files. Much better will be keep tags
with package.

> Counter proposal; use what you're proposing as a cache.  metadata.xml 
> is the proper place for this

++

> Roughly, and this is definitely a rough sketch:
> 
> 
>  tag1 tag2 tag2 tag3
>  awesomeness
> 

Since use dependencies eapi should be provided somewhere.

Also I like metadata.xml proposal since it'll be easy to use
per-category metadata.xml for all ebuilds to inherit.

--
Peter.

Re: [gentoo-dev] The Python problem

[Dirkjan Ochtman]

On Tue, Jun 28, 2011 at 13:48, Jorge Manuel B. S. Vicetto
 wrote:
> Yes, but with slotting you allow different packages to pull in different
> slots of python. Furthermore, when you slot a package and mark more than
> one slot stable, you're saying that all the stable slots work and don't
> "break" the tree.

And that's true for Python AFAICT.

> About the stages bug (330361), as was discussed to exhaustion on the
> bug, mls, IRC and many other locations, python3 isn't added to the
> stages by the will or work of releng.

Right; I've also stated my opinion on this exhaustively in that bug.

Cheers,

Dirkjan

Re: [gentoo-dev] The Python problem

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28-06-2011 07:19, Dirkjan Ochtman wrote:
> On Tue, Jun 28, 2011 at 08:54, Joshua Saddler  wrote:
>> This would be nice, but unfortunately the python maintainer forced
>> 3.x on everyone, despite the fact that nothing uses it and no one
>> really wanted it made the default. So now it's shipped with all the
>> stage tarballs, in addition to 2.7. You've got it whether you want it
>> or not.
>>
>> This is one of the things that needs to be rescinded, along with the
>> python eclass changes. Get everyone down to just one version
>> of python installed.
> 
> It's just slotting like everything else. (There's an open bug for the stages.)

Yes, but with slotting you allow different packages to pull in different
slots of python. Furthermore, when you slot a package and mark more than
one slot stable, you're saying that all the stable slots work and don't
"break" the tree.
About the stages bug (330361), as was discussed to exhaustion on the
bug, mls, IRC and many other locations, python3 isn't added to the
stages by the will or work of releng.

> Cheers,
> 
> Dirkjan
> 

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOCb93AAoJEC8ZTXQF1qEPurcQAKj3i7pL22kd2EpmG2+tDdcg
us3xE2dQofp6hVkiSkz6LVQuyCEH9QV/jujSkwYJLVPDsGGyXzBIkUGA9iLc2iDQ
nJx2r2QqZe11CxOuyd15AomVsLDazDGq8mxkxIBzJl9l9xS5HINqL+D79HxiOsdE
oraOL/cr4tbjDLWgraLZMXM/QPUkhqXkQurgn1uF4U4TAkvjZessJwe2Csi6raUW
xhJ42HAF+Q+VpFuTlBJfJevNsXnyHR4y6qM4xFF5X6sIyPodz3CORfHBMAXrU/pX
MCsMSPRJQRIAc26tEf+V4WJuUsp+yaydejPnEiyZSnDBDmgeS7zgEhQRLAPf+//Y
sMEMqchTAkwS4gxyAyl6AoR3+DFlGZdcTmn2S+AbtQNH318Lt3yamGbwRUMpjUHX
p8YXxsjL6iigyIUaJt594W1Bc2gS6ktkQGUqERLvM0dYUSoQcZJCeWq7y+qO/3vF
uukqOnljgSEvucijeHUM3623ImgpoCw3tzw7UGz74PunqqqL37op7FxX55exyYWw
TjzDqFEPlnaNQNvD3E3dZdU+/KnUlmn9Jtbxv/o04unVfEFspGP9DeuZYUOolWAG
86LFsL9PeSGLhqgxWbFjMR4lmznilnlaaB+4MmEtMV3K3FGdsI/68dhGRNe+oEC7
8JTT1DDZpunk0coni/f3
=aUwd
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

On Tue, 28 Jun 2011 12:19:43 +0100
Ciaran McCreesh  wrote:

> On Tue, 28 Jun 2011 13:14:40 +0200
> Michał Górny  wrote:
> > On Tue, 28 Jun 2011 12:03:28 +0100
> > Ciaran McCreesh  wrote:
> > > Have you seen how Exherbo solved the same problem? exheres-0 has
> > > 'suggested' and 'recommended' dependencies, which are variations
> > > on post dependencies. Suggested dependencies are displayed (along
> > > with a description explaining what they do for the packages
> > > suggesting them) but not taken by default, and recommended
> > > dependencies are taken (but shown as just being recommended)
> > > unless the user says not to.
> > 
> > Seems to me like just another configuration file for user to cope
> > with.
> 
> You obviously didn't pay attention, since the configuration file is
> the least relevant bit of the whole thing. If you really think that
> too many configuration files is a bigger problem than making
> reinstalls suddenly not reinstall stuff, though, then tracking
> not-taken suggestions is trivial.
> 
> Having real world experience with all of this, I can assure you that
> configuration files are not what cause user difficulties.

Ah, I missed the point of not having to rebuild packages.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Thoughts about broken package handling

[Peter Volkov]

В Втр, 28/06/2011 в 07:17 +0100, Ciaran McCreesh пишет:
> There was going to be a really simple, elegant, ebuild-controllable and
> provably working fix for that in EAPI 4 in the form of := deps, but
> they got dropped because Portage couldn't implement it.
> 
> Which is strange, because it should have been a ten minute job...

There is a good opportunity to  resubmit this for EAPI=5 ;)

--
Peter.

Re: [gentoo-dev] RFC: optinal run time dependencies

[Ciaran McCreesh]

On Tue, 28 Jun 2011 13:14:40 +0200
Michał Górny  wrote:
> On Tue, 28 Jun 2011 12:03:28 +0100
> Ciaran McCreesh  wrote:
> > Have you seen how Exherbo solved the same problem? exheres-0 has
> > 'suggested' and 'recommended' dependencies, which are variations on
> > post dependencies. Suggested dependencies are displayed (along with
> > a description explaining what they do for the packages suggesting
> > them) but not taken by default, and recommended dependencies are
> > taken (but shown as just being recommended) unless the user says
> > not to.
> 
> Seems to me like just another configuration file for user to cope
> with.

You obviously didn't pay attention, since the configuration file is the
least relevant bit of the whole thing. If you really think that too
many configuration files is a bigger problem than making reinstalls
suddenly not reinstall stuff, though, then tracking not-taken
suggestions is trivial.

Having real world experience with all of this, I can assure you that
configuration files are not what cause user difficulties.

> We can achieve the same results with the special USE Peter suggested
> and USE defaults, using the same configuration mechanism as usual.

You *could*, yes. But then that's yet another perversion on what USE
flags are, and it means that suddenly reinstalling isn't reinstalling
any more (what if a user wants to reinstall something, but that it
doesn't get reinstalled because the package mangler thinks that you're
just altering flags?). Do you really want a user to have to 'reinstall'
something twice to reinstall it?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: optinal run time dependencies

[Patrick Lauer]

On 06/28/11 12:38, Peter Volkov wrote:
> Hi guys. We've had discussion on optional runtime dependencies in bug
> 361255, but I think it's worth to have broader discussion of this issue.
> 
[SNIP]
> Comments?

I like the USEflag approach. It integrates well with the rest of the
machinery.

Speaking from experience with "other distros" that have optional
dependency support -
be really REALLY sure it's an absolutely optional feature that you
handle like this. There's nothing worse than spending 15 minutes trying
to figure out why stuff is broken, just to realize that the mandatory
optional dependencies were not installed. (Yes, mandatory. But optional.
Yey!)

Since we have useflags anyway I don't really see a strong usecase for
making some useflags different - we even have default-on and default-off
methods, and if a user doesn't like something it's easy to change
locally. But more metadata around the useflags might be very convenient.

> May be instead of ~ introduce three additional prefixes (~ and another
> two for +~ and -~ cases)?
That looks a bit weird :)




-- 
Patrick Lauer http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

On Tue, 28 Jun 2011 14:38:19 +0400
Peter Volkov  wrote:

> Starting with EAPI=X new prefix ~ is allowed in IUSE use flag
> definition. Use
> flags prefixed with ~ are not allowed to be used anywhere but only
> inside
> PDEPEND dependency specification. This USE flags are used during
> dependency
> resolution as normal. Package manager is allowed to skip
> re-installation of the
> package due to this USE flag change but still it should record such
> USE change
> into package database.

How about packages having optional rt dependencies on other packages'
optional dependencies?

> Comments?
> 
> May be instead of ~ introduce three additional prefixes (~ and another
> two for +~ and -~ cases)?

I think a USE_EXPAND prefix could be used for that as well.

We could then extend the backwards compatibility to cause complete
package rebuilds with older PMs (EAPIs) and only dep-switches for newer
ones.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

On Tue, 28 Jun 2011 12:03:28 +0100
Ciaran McCreesh  wrote:

> Have you seen how Exherbo solved the same problem? exheres-0 has
> 'suggested' and 'recommended' dependencies, which are variations on
> post dependencies. Suggested dependencies are displayed (along with a
> description explaining what they do for the packages suggesting them)
> but not taken by default, and recommended dependencies are taken (but
> shown as just being recommended) unless the user says not to.

Seems to me like just another configuration file for user to cope with.

We can achieve the same results with the special USE Peter suggested and
USE defaults, using the same configuration mechanism as usual.
-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: optinal run time dependencies

[Ciaran McCreesh]

On Tue, 28 Jun 2011 14:38:19 +0400
Peter Volkov  wrote:
> Hi guys. We've had discussion on optional runtime dependencies in bug
> 361255, but I think it's worth to have broader discussion of this
> issue.

Have you seen how Exherbo solved the same problem? exheres-0 has
'suggested' and 'recommended' dependencies, which are variations on
post dependencies. Suggested dependencies are displayed (along with a
description explaining what they do for the packages suggesting them)
but not taken by default, and recommended dependencies are taken (but
shown as just being recommended) unless the user says not to.

To avoid annoyance, there are two special cases. First, if a suggested
or recommended dependency is already installed, then it's treated like a
regular post dependency for upgrades etc (so you don't have to take
suggestions every single time). Second, there's a config file allowing
users to permanently 'untake' or 'take things.

So let's take an oversimplified 'git':

DEPENDENCIES="
suggestion:
dev-perl/TermReadKey [[
description = [ Dependency for 'git add --interactive' ]
]]

(
dev-perl/Authen-SASL
dev-perl/Net-SMTP-SSL
) [[
*description = [ Dependency for 'git send-email' ]
*group-name = [ git-send-email ]
]]
"

Here, when a user first tries to install 'git', they get something like
this (output abbreviated for clarity):

n   dev-scm/git:0::arbor 1.7.5.4 to ::installed
bash-completion curl -doc -emacs -ipv6 python

I did not take the following:

(n) dev-perl/TermReadKey:0::arbor 2.30 to ::installed
"Change terminal modes, and perform non-blocking reads"
Reasons: dev-scm/git (sug): "Dependency for 'git add --interactive'"
Take using: --take

(n) dev-perl/Authen-SASL:0::arbor 2.15 to ::installed
"Perl SASL Authentication framework"
Reasons: dev-scm/git (sug): "Dependency for 'git send-email'"
Take using: --take (git-send-email)

(n) dev-perl/Net-SMTP-SSL:0::arbor 1.01 to ::installed
"SSL support for Net::SMTP"
Reasons: dev-scm/git (sug): "Dependency for 'git send-email'"
Take using: --take (git-send-email)

Here, the user can just go ahead and install 'git' if they like --
untaken dependencies are just informational, not an error. Or they can
do some of the following:

* They can '--take TermReadKey' etc. Or they can use the 'group name',
  like '--take git-send-email', since suggested dependencies often come
  in groups and it's handy that way.

* Similarly, they can '--take-from git'. There's also '--ignore' and
  '--ignore-from'. They're not widely used in practice.

* They can update the 'suggestions.conf' file to record their choice.
  But this isn't usually necessary, because of the "if a suggestion is
  already installed, automatically take it" behaviour. It's mostly used
  to say "I've seen this suggestion, and don't want it, so don't show
  it to me again". Still, it's handy for suggestion groups if, say, git
  send-email's optional extra dependencies keep changing.

Seems to work rather well in practice...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] RFC: optinal run time dependencies

[Peter Volkov]

Hi guys. We've had discussion on optional runtime dependencies in bug
361255, but I think it's worth to have broader discussion of this issue.

=
Abstract

Optional runtime dependencies are dependent packages that are not
required to run program but when installed enhance program run-time
features. Below new use flag prefix is suggested to handle such rdeps.

Motivation

Optional run time dependencies are packages that are not required at
runtime
but when installed provide additional features for program. For example,
app-text/asciidoc works fine without media-gfx/graphviz, but to generate
diagrams from a textual specification media-gfx/graphviz have to be
installed.

Currently there are two common approaches for this problem:

1. add a use flag to control runtime dependency
2. add elog message into pkg_postinst to notify users that some features
depend
on installing package A, B, etc.

Both of this approaches are suboptimal.

Use-flags (1) will require user to rebuild package just to install
optional runtime
dependency.

elog messages do not present possible features during emerge --preted.
So 
after reading elog message this requires user to run another emerge just
to
have all asciidoc features installed.

elog-message approach complicates developement. Let's consider case
where
package foo depends on asciidoc with graph support. Without use flags 
foo-ver.ebuild have to contain something like:

RDEPEND="
app-text/asciidoc
media-gfx/graphviz"

Now it is possible that graph provider for app-text/asciidoc changes
(e.g. on
graphviz-ng). In such case all this packages that require asciidoc with
graph support
will have to be updated (controrary to use-flag approach where
asciidoc[graphviz]
dependency is sufficient).

Also sometimes more then one package is required to provide feature.
net-im/psi it requires both net-im/psimedia and app-crypt/qca-ossl:2 for
voice calls (jingle) support:

PDEPEND="
jingle? ( net-im/psimedia
app-crypt/qca-ossl:2 )"

net-im/psimedia builds fine without app-crypt/qca-ossl:2 but it is still
required
to have working jingle in psi. Such dependencies are not very evident
for
non-maintainer and may cause problems during upgrade if, say, another
bar
dependency will became required for jingle support, but user/developer
will be
not very attentive rereading yet another time ewarn messages.

Also elog approach adds text into anyway overloaded elog output.

Specification

Starting with EAPI=X new prefix ~ is allowed in IUSE use flag
definition. Use
flags prefixed with ~ are not allowed to be used anywhere but only
inside
PDEPEND dependency specification. This USE flags are used during
dependency
resolution as normal. Package manager is allowed to skip re-installation
of the
package due to this USE flag change but still it should record such USE
change
into package database.

Rationale

Since use-flag approach has only one drawback it's good idea to fix it.

Backwards Compatibility

This should be inside some future EAPI thus is backward compatible.
Already existing prefixes (+ and -) are allowed to be in any part of
prefix, i.e. IUSE="~foo ~+bar +~baz" should work.
=

Comments?

May be instead of ~ introduce three additional prefixes (~ and another
two for +~ and -~ cases)?

--
Peter.

Re: [gentoo-dev] Are tags just sets?

[Brian Harring]

On Tue, Jun 28, 2011 at 03:43:21PM +1200, Kent Fredric wrote:
> A. Storing tag data in metadata.xml   ( package -> tag association )
> B. Developing a tool that aggregates the contents of metadata.xml to
> produce a cache for the data going the other way ( tag -> package )
> 
> People searching for packages that match a tag will thusly be able to
> read this cached data ( Our primary use case )  and people who want to
> know what tags a specific package have will read/augment metadata.xml
> 
> I Believe both these parts are required for the design to be successful.
> 
> However, both parts have a bit of bike-shedding involved in them,
> part A of the system requires changes to exisiting structures, and
> part A requires bike shedding about part B's format.
> 
> For the sake of simplicity, I'm ( and I believe others ) are simply
> suggesting we develop part B first.

It's sub hour or so to look at the existing `egencache 
--update-use-local-desc` (specifically GenUseLocalDesc class) and 
implement such a cache.  It's not hard.

Either way, if you want this, the part that will take time is 
integrating it into emerge itself for searching; now if you want to 
write that code twice, go nuts, but someone lazier would do both at 
the same time to make sure they structured the API so it could 
support in one pass, rather than deploying an API, than having to 
shoehorn the cpv argument in.

If people want it, cut a patch and post it for feedback either way- 
bearing in mind that from where I'm sitting, deploying it half-assed 
requiring people to maintain a bunch of text files isn't a viable 
option ;)

~brian

Re: [gentoo-dev] ldconfig symlink updates -- do we need that?

[Michał Górny]

On Tue, 28 Jun 2011 10:48:48 +0200
Michał Górny  wrote:

> I have created a patch which makes 'env-update' always pass '-X' to
> ldconfig, to not let it update the symlinks in system-wide libdirs.
> I'm testing it right now to see if it doesn't cause any breakage.

And, as always, forgot to attach it. Here it goes.

-- 
Best regards,
Michał Górny
From 268d114e90cf3d20a816e194a5d8711e65060983 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Tue, 28 Jun 2011 10:10:36 +0200
Subject: [PATCH] Don't ever recreate root .so links on env-update.

We install .so symlinks with packages, so let's use that instead of
letting ldconfig update them for no reason. This should fix problems
with preserved-libs.
---
 man/env-update.1   |3 +--
 pym/portage/util/env_update.py |5 +
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/pym/portage/util/env_update.py b/pym/portage/util/env_update.py
index a89f2e2..a82afdf 100644
--- a/pym/portage/util/env_update.py
+++ b/pym/portage/util/env_update.py
@@ -248,10 +248,7 @@ def env_update(makelinks=1, target_root=None, prev_mtimes=None, contents=None,
 			# we can safely create links.
 			writemsg_level(_(">>> Regenerating %setc/ld.so.cache...\n") % \
 (target_root,))
-			if makelinks:
-os.system("cd / ; %s -r '%s'" % (ldconfig, target_root))
-			else:
-os.system("cd / ; %s -X -r '%s'" % (ldconfig, target_root))
+			os.system("cd / ; %s -X -r '%s'" % (ldconfig, target_root))
 		elif ostype in ("FreeBSD","DragonFly"):
 			writemsg_level(_(">>> Regenerating %svar/run/ld-elf.so.hints...\n") % \
 target_root)
-- 
1.7.6



signature.asc
Description: PGP signature

[gentoo-dev] ldconfig symlink updates -- do we need that?

[Michał Górny]

Hello,

As you may or may not know, right now env-update calls 'ldconfig'
by default, describing that in the terms of 'Regenerating
/etc/ld.so.cache'. In fact, it does a little more -- it updates library
symlinks to use the newest library version available.

In other words, if we've got libfoo.so.1.1 and .1.2 with the same
SONAME, and libfoo.so.1 symlinks to .1.1, ldconfig would replace that
by a symlink to .1.2.

This seems to be the major cause of the problems with portage's
preserve-libs feature. When a package is downgraded, portage replaces
the SONAME symlink with an older version to make newly-built packages
use that older version, and preserves the newer libraries not to break
linkage.

But a short while later, ldconfig takes over the symlink and makes it
point to the newer version once again. Packages still link to the newer
version and the only way to get the library actually downgraded is to
remove the preserved library. Thus, it's even worse than without
preserved-libs.

On the other hand, that ldconfig behavior seems completely redundant
as packages are installed with .so symlinks anyway. And I think that if
package manager installs those symlinks, it should manage them itself
instead of letting external tools mangle with PM-installed files.

I have created a patch which makes 'env-update' always pass '-X' to
ldconfig, to not let it update the symlinks in system-wide libdirs. I'm
testing it right now to see if it doesn't cause any breakage.

If that causes problems (i.e. some packages don't actually create
correct .so symlinks themselves), I guess we could decide to call
'ldconfig -N -n' in post-install operations, like the deprecated
'preplib' helper does.

This way, the symlinks will be completely controlled by the Package
Manager and the preserve-libs feature should handle downgrades just
fine.

And I've just downgraded libav, and rebuilt mplayer2 against it with
the newer version being preserved just fine.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] The Python problem

[Michał Górny]

On Tue, 28 Jun 2011 10:04:58 +0200
Dirkjan Ochtman  wrote:

> On Mon, Jun 27, 2011 at 21:31, Michał Górny  wrote:
> > Working targets. USE_PYTHON is junk. What python.eclass does now
> > with ABIs is a PITA, and requires manually providing a lot of
> > redudant information (namely, RESTRICT_PYTHON_ABIS).
> 
> Please clarify *why* it is a PITA, and what information is redundant.

Let's put it like that. I have package foo which support py2 and py3.
It depends on package bar which once supported py3 but the newest
version is known to be broken with py3, and thus breaks building my
package as well.

And right now there's no real way to handle that dependency. With
SLOT-USEdeps I could do 'bar[py3=]'. With current state of Python
eclass I have to restrict ABIs to match newer version and/or restrict
dependency versions which is awfully redundant.

> > I'd like to see that fixed somehow. I'd like to set a single
> > supported Python version information in an ebuild, and let the
> > dependency resolver handle everything else.
> 
> That would be bad; it's common and useful to have packages installed
> in both 2.6 and 2.7 (and even 3.1).

I think you misunderstood me. I mean generating the whole dependency
tree from support Python versions. Like dropping version info from
PYTHON_DEPEND in favor of RESTRICT_PYTHON_ABIS.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: REMOVE

[Duncan]

Stelios Boulios posted on Tue, 28 Jun 2011 09:51:41 +0300 as excerpted:

[blank, see subject]

See the headers for any post forwarded by this list.
They all contain the following information:

List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 
List-Id: Gentoo Linux mail 

It would appear that you want to mail the address in List-Unsubscribe 
(you missed the +unsubscribe bit).  Be sure to watch for the confirming 
unsubscribe mail and confirm it as required.

-- 
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

Re: [gentoo-dev] The Python problem

[Dirkjan Ochtman]

On Mon, Jun 27, 2011 at 22:46, Petteri Räty  wrote:
>> Sure, but if that means the developers now have to bump every package
>> in the tree when a new version of Python comes out, I'm not sure
>> that's the best trade-off.
>
> And why can't this be handled by the eclass? If the ebuild is able to
> specify it supports >=3.0 meaning it's expected that future versions
> work then the eclass can make the new values available through IUSE when
> new python versions are out and ebuilds don't require any changes.

I'd be happy to get that to work, it seems like a good solution.

Cheers,

Dirkjan

Re: [gentoo-dev] The Python problem

[Dirkjan Ochtman]

On Mon, Jun 27, 2011 at 21:31, Michał Górny  wrote:
> Working targets. USE_PYTHON is junk. What python.eclass does now with
> ABIs is a PITA, and requires manually providing a lot of redudant
> information (namely, RESTRICT_PYTHON_ABIS).

Please clarify *why* it is a PITA, and what information is redundant.

> Right now, each ebuild has to provide the same information in
> PYTHON_DEPEND and RESTRICT_PYTHON_ABIS. Moreover, if an ebuild
> supports, say, py3 and its dependency doesn't, the ebuild has to
> restrict py3 too.

I'll grant you that PYTHON_DEPEND and RESTRICT_PYTHON_ABIS seem
redundant, we could probably fix that.

> I'd like to see that fixed somehow. I'd like to set a single supported
> Python version information in an ebuild, and let the dependency
> resolver handle everything else.

That would be bad; it's common and useful to have packages installed
in both 2.6 and 2.7 (and even 3.1).

Cheers,

Dirkjan

Re: [gentoo-dev] The Python problem

[Dirkjan Ochtman]

On Mon, Jun 27, 2011 at 20:23, Benedikt Böhm  wrote:
> the way python applications are built currently renders all binary
> packages useless, since portage does not know which version of python
> it was built against. the explicit selection with RUBY_TARGETS or
> PHP_TARGETS solves this problem at the small cost of commiting new
> values to these variables from time to time.

I don't think updating all Python packages every two years is a small
cost, particularly when a large percentage of those packages will just
work on the new version.

(Another problem with the current Ruby approach is that it's
impossible to support unstable interpreters or versions from in stable
package versions, such that Ruby packages now often have multiple
ebuild revisions for stable and unstable interpreters.)

Cheers,

Dirkjan

Re: [gentoo-dev] The Python problem

[Dirkjan Ochtman]

On Tue, Jun 28, 2011 at 08:54, Joshua Saddler  wrote:
> This would be nice, but unfortunately the python maintainer forced
> 3.x on everyone, despite the fact that nothing uses it and no one
> really wanted it made the default. So now it's shipped with all the
> stage tarballs, in addition to 2.7. You've got it whether you want it
> or not.
>
> This is one of the things that needs to be rescinded, along with the
> python eclass changes. Get everyone down to just one version
> of python installed.

It's just slotting like everything else. (There's an open bug for the stages.)

Cheers,

Dirkjan