On Wed, 03 Dec 2008 02:05:31 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:
> metadata.xml already contains data that eix and other software should
> be able to search in (like longdescriptions), and having each package
> in kde-base report http://www.kde.org/ as its homepage is kinda
On Mon, 01 Dec 2008 10:00:33 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:
> "Alec Warner" <[EMAIL PROTECTED]> writes:
>
> > That being said I still don't see the usefulness here.
> >
> > You seem to think that using the existing APIs for this data is
> > wrong, and I think the oppos
James Cloos <[EMAIL PROTECTED]> writes:
> Searching is an important reason for every package to specify its homepage.
And?
metadata.xml already contains data that eix and other software should be
able to search in (like longdescriptions), and having each package in
kde-base report http://www.kde
> "Diego" == Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> writes:
>> But also the need to replicate http://www.kde.org/ to metadata.xml of
>> all KDE split ebuilds -- right now, this is set by an eclass.
Diego> The usefulness of this is IMHO debatable; why not just writing it one
Diego> pack
> "Jan" == Jan Kundrát <[EMAIL PROTECTED]> writes:
>> - less data in metadata cache;
Jan> Isn't it in the cache for some reason? Really, I'm just asking.
If for nothing else, so that update-eix can get it to allow searching on
homepage. And, yes, that is an important feature. And, no, open
"Alec Warner" <[EMAIL PROTECTED]> writes:
> That being said I still don't see the usefulness here.
>
> You seem to think that using the existing APIs for this data is wrong,
> and I think the opposite, so I guess we will agree to disagree on this
> matter.
Yeah I still think that there is no poin
On Mon, Dec 1, 2008 at 12:24 AM, Diego 'Flameeyes' Pettenò
<[EMAIL PROTECTED]> wrote:
> "Alec Warner" <[EMAIL PROTECTED]> writes:
>
>> - Space savings. Certainly your scheme may be smaller, but the XML
>> tag overhead may eat into the savings. You should do some estimates
>> to show the community
Jan Kundrát <[EMAIL PROTECTED]> writes:
> But also the need to replicate http://www.kde.org/ to metadata.xml of
> all KDE split ebuilds -- right now, this is set by an eclass.
The usefulness of this is IMHO debatable; why not just writing it one
package (say kde-base/kde or kde-meta) and just the
"Alec Warner" <[EMAIL PROTECTED]> writes:
> - Space savings. Certainly your scheme may be smaller, but the XML
> tag overhead may eat into the savings. You should do some estimates
> to show the community how much smaller the tree will be from this
> proposal.
Sorry but you lost me on any point
On Sun, Nov 30, 2008 at 3:12 PM, Diego 'Flameeyes' Pettenò
<[EMAIL PROTECTED]> wrote:
> "Alec Warner" <[EMAIL PROTECTED]> writes:
>
>> Diego, What are the concrete benefits of your proposal?
>
> As I said:
>
> - no need to replicate homepage data between versions; even though forks
> can change ho
On Mon, 01 Dec 2008 00:12:23 +0100
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote:
> - no need to replicate homepage data between versions; even though
> forks can change homepage, I would expect that to at worse split in
> two a package, or have to be different by slot, like Java;
You mean "
Diego 'Flameeyes' Pettenò wrote:
- no need to replicate homepage data between versions; even though forks
can change homepage, I would expect that to at worse split in two a
package, or have to be different by slot, like Java;
But also the need to replicate http://www.kde.org/ to metadata.x
"Alec Warner" <[EMAIL PROTECTED]> writes:
> Diego, What are the concrete benefits of your proposal?
As I said:
- no need to replicate homepage data between versions; even though forks
can change homepage, I would expect that to at worse split in two a
package, or have to be different by slot
Tobias Scherbaum <[EMAIL PROTECTED]> writes:
> "dev-java/sun-jdk" unnecessarily. Reducing this to restrict="1.4" isn't
> easily readable as you'd need to know that restrict would specify a
> slot. If your plan is to make it easier to find useful information about
> a package (without using a fancy
Diego 'Flameeyes' Pettenò wrote:
> Tobias Scherbaum <[EMAIL PROTECTED]> writes:
>
> > But what about additional slot or version attributes like
> > http://java.sun.com/j2se/1.4.2/
> > (or a version attribute)? If slot and version aren't specified they'd be
> > interpreted as wildcards.
>
>
>
>
Tobias Scherbaum <[EMAIL PROTECTED]> writes:
> But what about additional slot or version attributes like
> http://java.sun.com/j2se/1.4.2/
> (or a version attribute)? If slot and version aren't specified they'd be
> interpreted as wildcards.
The restrict attribute exists already and it's better
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes:
> I have a very quick proposal: why don't we move the packages' homepage
> in metadata.xml (since it's usually unique for all the versions) and we
> get rid of the variable for the next EAPI version?
I forgot to say that this also addresses, f
Jan Kundrát <[EMAIL PROTECTED]> writes:
> I believe the reason was that HOMEPAGE might change with new versions
> and that metadata.xml didn't (doesn't?) support version-specific data.
At least the maintainer and (iirc, at least that's how we proposed
it the first time around) flag tags support a
18 matches
Mail list logo
