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 07-15-2008, 06:06 PM
Ciaran McCreesh
 
Default Council meeting summary for 10 July 2008

On Tue, 15 Jul 2008 13:58:36 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Would it be more constructive to create a list of new
> features/capabilities that depend on this GLEP. For each I'd define:
>
> 1. The feature/unmet need.
> 2. Why it can't be done or can only be done poorly without the new
> GLEP. 3. When we're likely to see the feature become available
> assuming the GLEP were approved.
> 4. What package managers are likely to implement it. (Ie their
> maintainers endorse the need.
>
> It sounds like this list might already have some items on it - so why
> not document them?

The GLEP already documents what needs it, in the broadest reasonable
terms. The problem with specifics is that everyone will then start
arguing about how exactly, say, per-cat/pkg eclasses would work, which
is irrelevant to the GLEP.

--
Ciaran McCreesh
 
Old 07-15-2008, 07:07 PM
Doug Goldstein
 
Default Council meeting summary for 10 July 2008

Tiziano Mller wrote:

Donnie Berkholz wrote:



Hi all,

Here is the summary from Thursday's council meeting. The complete log
will show up at http://www.gentoo.org/proj/en/council/ shortly.




wrt GLEP 56:

i) I don't see a specification when use.local.desc is finally going to be
dropped
ii) Why not switch to XML for use.desc as well? (just to be consequent)
We could then use XInclude in a package's metadata.xml to include a global
use.desc.xml in <use>...</use>
(The requirements could then be changed to: the USE flags description has to
be written in the packages metadata.xml)



Incremental steps are better then one huge sweeping change. It'll allow
us to evaluate the needs and goals of the project as we move forward.
The big concern with dropping use.desc is that multiple USE flags that
do the same thing will start to pop up across the whole tree because
developers won't know that a USE flag already exists for feature X.

--
gentoo-dev@lists.gentoo.org mailing list
 
Old 07-15-2008, 08:50 PM
Tiziano Mller
 
Default Council meeting summary for 10 July 2008

Donnie Berkholz wrote:

> Hi all,
>
> Here is the summary from Thursday's council meeting. The complete log
> will show up at http://www.gentoo.org/proj/en/council/ shortly.
>

wrt GLEP 56:

i) I don't see a specification when use.local.desc is finally going to be
dropped
ii) Why not switch to XML for use.desc as well? (just to be consequent)
We could then use XInclude in a package's metadata.xml to include a global
use.desc.xml in <use>...</use>
(The requirements could then be changed to: the USE flags description has to
be written in the packages metadata.xml)


--
gentoo-dev@lists.gentoo.org mailing list
 
Old 07-16-2008, 06:50 PM
Doug Goldstein
 
Default Council meeting summary for 10 July 2008

Tiziano Mller wrote:

Doug Goldstein wrote:



Tiziano Mller wrote:


Donnie Berkholz wrote:




Hi all,

Here is the summary from Thursday's council meeting. The complete log
will show up at http://www.gentoo.org/proj/en/council/ shortly.




wrt GLEP 56:

i) I don't see a specification when use.local.desc is finally going to be
dropped
ii) Why not switch to XML for use.desc as well? (just to be consequent)
We could then use XInclude in a package's metadata.xml to include a
global use.desc.xml in <use>...</use>
(The requirements could then be changed to: the USE flags description has
to be written in the packages metadata.xml)





Incremental steps are better then one huge sweeping change. It'll allow
us to evaluate the needs and goals of the project as we move forward.


I agree.



The big concern with dropping use.desc is that multiple USE flags that
do the same thing will start to pop up across the whole tree because
developers won't know that a USE flag already exists for feature X.


I'd not drop use.desc, I'd substitute it with an XML-based file using a
similar (or the same) syntax as metadata.xml.
But instead of having the package manager (or other tools operating with USE
flags/USE flag descriptions) to lookup in either a package's metadata.xml
_or_ a global use.desc.xml, I'd use XInclude in metadata.xml (which then
includes the global use.desc.xml) such that the package manager (or other
tools) just have to consider a package's metadata.xml.
This approach would make it possible to have more than one use.desc.xml.
For example for kde or gnome related global USE-flags: kde.use.desc.xml or
gnome.use.desc.xml.


If you write the code....

That's the biggest issue with features and ideas people propose. No one
is willing to sit down and write the code necessary. Look at how many
GLEPs set unimplemented because of lack of code.


This also involves increasing the XML support in every package manager,
which is not going to be a small undertaking.

--
gentoo-dev@lists.gentoo.org mailing list
 
Old 07-16-2008, 07:00 PM
Patrick Brjesson
 
Default Council meeting summary for 10 July 2008

On 2008-07-16 14:50, Doug Goldstein uttered these thoughts:
> Tiziano Mller wrote:
> This also involves increasing the XML support in every package manager,
> which is not going to be a small undertaking.

I'd say near to impossible in at least one case

--
() The ASCII Ribbon Campaign - against HTML Email
/ and proprietary formats.
 
Old 07-16-2008, 07:52 PM
Tiziano Mller
 
Default Council meeting summary for 10 July 2008

Doug Goldstein wrote:

> Tiziano Mller wrote:
>> Donnie Berkholz wrote:
>>
>>
>>> Hi all,
>>>
>>> Here is the summary from Thursday's council meeting. The complete log
>>> will show up at http://www.gentoo.org/proj/en/council/ shortly.
>>>
>>>
>>
>> wrt GLEP 56:
>>
>> i) I don't see a specification when use.local.desc is finally going to be
>> dropped
>> ii) Why not switch to XML for use.desc as well? (just to be consequent)
>> We could then use XInclude in a package's metadata.xml to include a
>> global use.desc.xml in <use>...</use>
>> (The requirements could then be changed to: the USE flags description has
>> to be written in the packages metadata.xml)
>>
>>
>>
> Incremental steps are better then one huge sweeping change. It'll allow
> us to evaluate the needs and goals of the project as we move forward.
I agree.

> The big concern with dropping use.desc is that multiple USE flags that
> do the same thing will start to pop up across the whole tree because
> developers won't know that a USE flag already exists for feature X.
I'd not drop use.desc, I'd substitute it with an XML-based file using a
similar (or the same) syntax as metadata.xml.
But instead of having the package manager (or other tools operating with USE
flags/USE flag descriptions) to lookup in either a package's metadata.xml
_or_ a global use.desc.xml, I'd use XInclude in metadata.xml (which then
includes the global use.desc.xml) such that the package manager (or other
tools) just have to consider a package's metadata.xml.
This approach would make it possible to have more than one use.desc.xml.
For example for kde or gnome related global USE-flags: kde.use.desc.xml or
gnome.use.desc.xml.


--
gentoo-dev@lists.gentoo.org mailing list
 
Old 07-20-2008, 01:38 PM
Peter Volkov
 
Default Council meeting summary for 10 July 2008

В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> Which part of the 'Problem' section in the GLEP didn't you understand?
> Do you seriously consider not being able to add or change global scope
> functions in future EAPIs to be a non-issue, or were you ignoring those
> two bullet points?

I've read all previous discussions but still miss answer to the
question: Why is it impossible to state that .ebuild extension is for
bash based ebuild make package manager get and filter EAPIs based on
EAPI variable?

Note, I assume that we can do not backward-compatible changes in PM, we
just need to wait enough time to start using it. But taking into account
that the features that will make use of this GLEP55 are still not so
evident I don't see any problem to wait. In any case I'd like to
understand why should we start support this hell of extensions.

--
Peter.
 
Old 07-20-2008, 01:56 PM
Ciaran McCreesh
 
Default Council meeting summary for 10 July 2008

On Sun, 20 Jul 2008 17:38:32 +0400
Peter Volkov <pva@gentoo.org> wrote:
> В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> > Which part of the 'Problem' section in the GLEP didn't you
> > understand? Do you seriously consider not being able to add or
> > change global scope functions in future EAPIs to be a non-issue, or
> > were you ignoring those two bullet points?
>
> I've read all previous discussions but still miss answer to the
> question: Why is it impossible to state that .ebuild extension is for
> bash based ebuild make package manager get and filter EAPIs based on
> EAPI variable?

I think your question is missing a word or something. I'm not entirely
sure what you're trying to ask...

But if you're asking why we can't use the EAPI variable, it's because
we can't get the EAPI variable unless we already know what it is. It's
only possible currently because all EAPIs have identical global scope
functions and environment requirements, but future EAPIs want to change
things there.

> In any case I'd like to understand why should we start support this
> hell of extensions.

Why do you think it's hell? It's just as easy as having an EAPI
variable inside the ebuild, and has the added advantage that your
editor of choice can start doing EAPI-aware syntax highlighting for you.

--
Ciaran McCreesh
 
Old 07-20-2008, 02:08 PM
Patrick Börjesson
 
Default Council meeting summary for 10 July 2008

On 2008-07-20 17:38, Peter Volkov uttered these thoughts:
> В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> > Which part of the 'Problem' section in the GLEP didn't you understand?
> > Do you seriously consider not being able to add or change global scope
> > functions in future EAPIs to be a non-issue, or were you ignoring those
> > two bullet points?
>
> I've read all previous discussions but still miss answer to the
> question: Why is it impossible to state that .ebuild extension is for
> bash based ebuild make package manager get and filter EAPIs based on
> EAPI variable?

Because that would still not allow global scope changes, because in order
to get to know which EAPI the ebuild is written in, you have to actually
source the ebuild, and by then it's too late.

Unless you introduce some inane requirement that the EAPI variable has
to be the first thing stated in the ebuild and force the PMs to extract
that value before actually starting to parse the ebuild. Now, if
_that's_ not an ugly solution, i don't know what is...

You have to know _how_ to interpret an ebuild _before_ you actually start
doing it.

> Note, I assume that we can do not backward-compatible changes in PM, we
> just need to wait enough time to start using it. But taking into account
> that the features that will make use of this GLEP55 are still not so
> evident I don't see any problem to wait. In any case I'd like to
> understand why should we start support this hell of extensions.

Reasons for the change has been stated before, and the one i just
explained is the main one so far as i know.

--
() The ASCII Ribbon Campaign - against HTML Email
/ and proprietary formats.
 

Thread Tools




All times are GMT. The time now is 07:44 AM.

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