[gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]


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?

This makes it easier to get the package's homepage for submitting bugs
upstream (you just do a single lookup for the metadata.xml file rather
than checking the ebuild; ensures that homepage changes don't get stale
for old revisions, avoids commits on old ebuilds for home page changes
(and thus changes that propagates on mirrors, and so on. It also makes
searching by homepage easier (a search program would take much less time
to parse XML that an ebuild).

I would propose an implementation of this that takes in consideration
also older proposals of having a way to specify upstream and
gentoo-specific information, something among the lines of this:

<link type="homepage">http://package.foobar.com</link>
<link type="bugtracker">http://package.foobar.com/bugs</link>

and for gentoo-specific

<link type="gentoo:devel" title="foobar maintainer's
guide">http://www.gentoo.org/proj/en/foo/foobar</link>

<link
type="gentoo:user" title="foobar usage
guide">http://www.gentoo.org/doc/en/foobar.xml</link>

Please submit all comments, as long as they are not "I don't like XML"
or "XML is the wrong answer" and similar since the point here is not to
discuss the format of metadata but rather where to have it.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/


[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Diego 'Flameeyes' Pettenò wrote:
> 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)

I believe the reason was that HOMEPAGE might change with new versions 
and that metadata.xml didn't (doesn't?) support version-specific data.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Jan Kundrát <jkt@gentoo.org> 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 restrict attribute.

But I really expect that as long as the package is the same, homepage is
unlikely to change with version; maybe with slot I guess, but even that
is debatable and somewhat rare I think.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Jan Kundrát:
> Diego 'Flameeyes' Pettenò wrote:
> > 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)
> 
> I believe the reason was that HOMEPAGE might change with new versions 
> and that metadata.xml didn't (doesn't?) support version-specific data.

In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
Does someone have an example where older versions stay at an old homepage
and newer versions moved to a new homepage? Which (and how many) packages would be affected by that?

If this does affect a larger number of packages (i doubt so) we might add something like this:
<link type="homepage:old">http://package.oldbarfoo.org</link>
or we allow more than 1 homepage item to be specified of which we can
use the title attribute to describe for which versions this homepage
item applies. Anyways, all of these would only be quick hacks for a
rather short timeframe which it takes to stable a new version and remove
the older one.

In general I do like that proposal, especially the addition of further
links for bug trackers, forums, irc-channels, gentoo-specific
documentation and so on.

  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Serkan Kaba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tobias Scherbaum yazmış:
> Jan Kundrát:
>> Diego 'Flameeyes' Pettenò wrote:
>>> 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)
>> I believe the reason was that HOMEPAGE might change with new versions 
>> and that metadata.xml didn't (doesn't?) support version-specific data.
> 
> In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
> Does someone have an example where older versions stay at an old homepage
> and newer versions moved to a new homepage? Which (and how many) packages would be affected by that?
> 
> If this does affect a larger number of packages (i doubt so) we might add something like this:
> <link type="homepage:old">http://package.oldbarfoo.org</link>
> or we allow more than 1 homepage item to be specified of which we can
> use the title attribute to describe for which versions this homepage
> item applies. Anyways, all of these would only be quick hacks for a
> rather short timeframe which it takes to stable a new version and remove
> the older one.
> 
> In general I do like that proposal, especially the addition of further
> links for bug trackers, forums, irc-channels, gentoo-specific
> documentation and so on.
> 
>   Tobias

I don't know if there are others but I can give one specific example,
sun-{jdk,jre-bin} where homepage differs in SLOT's
1.4 pointing to http://java.sun.com/j2se/1.4.2/ , 1.5 to
http://java.sun.com/j2se/1.5.0/ , 1.6 to http://java.sun.com/javase/6/
and 1.7 will probably have something new.

- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkym5wACgkQRh6X64ivZaKyWQCbBuzASFIYg+Ua5rifXVbig0RA
c+wAnRdETeKiyDESLKspQ52uNAHx+HrL
=OPAH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

Serkan Kaba wrote:
> I don't know if there are others but I can give one specific example,
> sun-{jdk,jre-bin} where homepage differs in SLOT's
> 1.4 pointing to http://java.sun.com/j2se/1.4.2/ , 1.5 to
> http://java.sun.com/j2se/1.5.0/ , 1.6 to http://java.sun.com/javase/6/
> and 1.7 will probably have something new.

A special case in which HOMEPAGE="java.sun.com" might work as well? ;)
Ok, of course this on purpose and might be of benefit to be pointed to a
specific website in that case.

But what about additional slot or version attributes like
<link type="homepage" slot="1.4">http://java.sun.com/j2se/1.4.2/</link>
(or a version attribute)? If slot and version aren't specified they'd be
interpreted as wildcards.

  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Tobias Scherbaum <dertobi123@gentoo.org> writes:

> But what about additional slot or version attributes like
> <link type="homepage" slot="1.4">http://java.sun.com/j2se/1.4.2/</link>
> (or a version attribute)? If slot and version aren't specified they'd be
> interpreted as wildcards.

<link type="homepage" restrict="dev-java/sun-jdk:1.4">

The restrict attribute exists already and it's better to reuse the same
code, isn't it?

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

Diego 'Flameeyes' Pettenò wrote:
> Tobias Scherbaum <dertobi123@gentoo.org> writes:
> 
> > But what about additional slot or version attributes like
> > <link type="homepage" slot="1.4">http://java.sun.com/j2se/1.4.2/</link>
> > (or a version attribute)? If slot and version aren't specified they'd be
> > interpreted as wildcards.
> 
> <link type="homepage" restrict="dev-java/sun-jdk:1.4">
> 
> The restrict attribute exists already and it's better to reuse the same
> code, isn't it?

In general yes, but in that case you're duplicating info like
"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 frontend, just reading the metadata.xml
with $EDITOR) slot="1.4" (or a version attribute) might be a tad more
human readable. 

  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

Tobias Scherbaum <dertobi123@gentoo.org> 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 frontend, just reading the metadata.xml
> with $EDITOR) slot="1.4" (or a version attribute) might be a tad more
> human readable. 

Well if we go to these things we should just apply the same to the other
attributes using restrict, since we want to have something coherent,
don't we? ;)

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Sun, 2008-11-30 at 14:50 +0100, Tobias Scherbaum wrote:
> Jan Kundrát:
> > Diego 'Flameeyes' Pettenò wrote:
> > > 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)
> > 
> > I believe the reason was that HOMEPAGE might change with new versions 
> > and that metadata.xml didn't (doesn't?) support version-specific data.
> 
> In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
> Does someone have an example where older versions stay at an old homepage
> and newer versions moved to a new homepage? Which (and how many) packages would be affected by that?

I've seen this happen for at least one ruby package where the package
got forked, with the old stagnant versions still on the old homepage and
the new versions on the new homepage.

I still favor the move to metadata.xml, even though there are probably a
few more edge cases like this.

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Peter Volkov]

В Вск, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:
> In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
> Does someone have an example where older versions stay at an old homepage
> and newer versions moved to a new homepage?

Yes. This is quite a common case when one upstream stopped development
of the package and new developer took it. traceroute, flow-tools are
just examples from the top of my head. I remember I saw more such
things...

Also sometimes it's useful to have different HOMEPAGE for different
versions.


And in general, Diego. What are you trying to improve with this change?
The original intention was to separate common information from all
ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
to ebuild. Now if intention is separate some information from ebuild
into metadata.xml then, please, tell me what is the criterion for such
information? Why not LICENSE? Currently I don't think this change worth
our efforts...

-- 
Peter.

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Serkan Kaba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Volkov yazmış:
> В Вск, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:
>> In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
>> Does someone have an example where older versions stay at an old homepage
>> and newer versions moved to a new homepage?
> 
> Yes. This is quite a common case when one upstream stopped development
> of the package and new developer took it. traceroute, flow-tools are
> just examples from the top of my head. I remember I saw more such
> things...
> 
> Also sometimes it's useful to have different HOMEPAGE for different
> versions.
> 
> 
> And in general, Diego. What are you trying to improve with this change?
> The original intention was to separate common information from all
> ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
> to ebuild. Now if intention is separate some information from ebuild
> into metadata.xml then, please, tell me what is the criterion for such
> information? Why not LICENSE? Currently I don't think this change worth
> our efforts...
> 
LICENSE should definetely be avoided to be defined per-package. Upstream
may decide to relicense new version of packages.
- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkyrJ0ACgkQRh6X64ivZaI4EwCfWECIM3Hecu04yHCeoCKEJqki
VMQAnj+aIeQ5Bf9cA0iQm/wT8U7hZWAV
=wW6Q
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Peter Volkov]

В Вск, 30/11/2008 в 17:09 +0200, Serkan Kaba пишет:
> Peter Volkov yazmış:
> > Also sometimes it's useful to have different HOMEPAGE for different
> > versions.
> > 
> > And in general, Diego. What are you trying to improve with this change?
> > The original intention was to separate common information from all
> > ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
> > to ebuild. Now if intention is separate some information from ebuild
> > into metadata.xml then, please, tell me what is the criterion for such
> > information? Why not LICENSE? Currently I don't think this change worth
> > our efforts...
> > 
> LICENSE should definetely be avoided to be defined per-package. Upstream
> may decide to relicense new version of packages.

Well, actually the reason we should avoid LICENSES in metadata.xml is
that it's used by portage and possibly at some point of time it'll be
possible to filter packages based on LICENSE. But the general question
still stands: what is the criterion we should use to separate variables
from .ebuild into metadata.xml and what are the benefits of such
separation?

-- 
Peter.

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Alec Warner]

On Sun, Nov 30, 2008 at 8:53 AM, Peter Volkov <pva@gentoo.org> wrote:
> В Вск, 30/11/2008 в 17:09 +0200, Serkan Kaba пишет:
>> Peter Volkov yazmış:
>> > Also sometimes it's useful to have different HOMEPAGE for different
>> > versions.
>> >
>> > And in general, Diego. What are you trying to improve with this change?
>> > The original intention was to separate common information from all
>> > ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
>> > to ebuild. Now if intention is separate some information from ebuild
>> > into metadata.xml then, please, tell me what is the criterion for such
>> > information? Why not LICENSE? Currently I don't think this change worth
>> > our efforts...
>> >
>> LICENSE should definetely be avoided to be defined per-package. Upstream
>> may decide to relicense new version of packages.
>
> Well, actually the reason we should avoid LICENSES in metadata.xml is
> that it's used by portage and possibly at some point of time it'll be
> possible to filter packages based on LICENSE. But the general question
> still stands: what is the criterion we should use to separate variables
> from .ebuild into metadata.xml and what are the benefits of such
> separation?

Going to randomly jump in, partially because I have a comment here.

Ebuilds are already filterable by license in portage, Marius
implemented that a while ago.  I'm sure the other package managers
have similar filtering abilities.

To the general thread:

Anecdotal evidence is stupid.  No one cares if one of your packages
has a different homepage per version.
Go scan the tree and show how many packages have this problem and we
can at least have useful data then (X% of the tree).

Zac, if we ask you to prioritize elibs, how long do you think
implementation will take?

Diego, What are the concrete benefits of your proposal?

All,

It is important to note that we are a large diverse group of folks and
when you propose global changes you have to be willing to sell your
idea to a large number of folks or implement it alone.  Coming to a
list with no data and no real 'pros/cons' data for your idea isn't not
a good way to sell it to anyone.

However cool the idea is, it is *never* obvious to everyone.  It is
never cost free.

-Alec

>
> --
> Peter.
>
>
>

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]

"Alec Warner" <antarus@gentoo.org> 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, like Java;
- allows proper handling of packages lacking a HOMEPAGE;
- less data in metadata cache;
- users can check the metadata much more easily by just opening the xml
  file or interfacing to that rather than having to skim through the
  ebuild, the xml files are probably more user readable then ebuilds
  using multiple eclasses;
- displaying info about the package does not require parsing the full
  ebuild file, with its eclasses;
- extensible to provide more links than just the homepage (forums,
  trackers, gentoo-specific documentation, ...);
- if we also move DESCRIPTION, search software can ignore everything
  about ebuild parsing, and just use the metadata.xml files; considering
  how many people actually use or used eix, it would make sense to allow
  third-party applications to be able to search through the tree;
- webapps like packages.gentoo.org would be able to display basic
  information without having to parse the ebuilds or the metadata cache.
- as much as people might think metadata is easier to parse than
  anything, XML has one huge advantage: there are plently of parsers for
  any language without having to actually write one, even as easy as it
  can be, and it's easily interfaced with anything; I wrote a simple XSL
  file that outputs the basic metadata details for packages without
  having any parser or executable code but xsltproc (or any other XSLT
  software), correlating data with herds.xml too;
- it really is metadata, and it makes very little sense to need parsing
  of eclasses and EAPI handling to get some data from a package that is
  non-functional in nature and free form (just like DESCRIPTION, and
  unlike LICENSE like Alec said), and that changes at worse once each
  slot (unlike LICENSE that can change at any given version).

Disadvantages:

- it requires user-interface software to parse metadata.xml to show
  data for a package; which is already needed to show per-package USE
  flag meaning;

General points:

- it does not solve unrelated problems like code replication;

Can someone come up with any other point beside "I don't like XML"
(which I already said is a puny answer) and "it can theorically be 10
different homepages for 10 different versions" (which I have sincerely
some beef with myself since if you fork a software you might as well
change its name)?

As I said, moving out the HOMEPAGE field from a package manager
prospective is non functional; if you're showing to the user some data
about a package you might as well show as much as you can, like long
descriptions, other links, and USE flags. And the fact that you can ask
the package manager for something is for me not a valid reason to avoi
moving something in a more approchable place for other software.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

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.xml of 
all KDE split ebuilds -- right now, this is set by an eclass.

> - allows proper handling of packages lacking a HOMEPAGE;

Could you elaborate a bit about how different is handling of an 
empty/uninitialized shell variable from an empty XML element?

> - less data in metadata cache;

Isn't it in the cache for some reason? Really, I'm just asking.

> - users can check the metadata much more easily by just opening the xml
>   file or interfacing to that rather than having to skim through the
>   ebuild, the xml files are probably more user readable then ebuilds
>   using multiple eclasses;

Haven't we already agreed that accessing ebuilds/... directly is broken 
by design?

> - webapps like packages.gentoo.org would be able to display basic
>   information without having to parse the ebuilds or the metadata cache.

Except for the ebuilds which still use the old format (that is 100% of 
the tree right now)

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Jan Kundrát <jkt@gentoo.org> 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 there? Having each
mini-package express itself as having that as its homepage is not very
useful to me, but I guess it's debatable.

>> - allows proper handling of packages lacking a HOMEPAGE;
>
> Could you elaborate a bit about how different is handling of an
> empty/uninitialized shell variable from an empty XML element?

That you can provide _other_ links beside an homepage, like
"unmaintained", "gentoo:userguide" and stuff like that so that user
don't just get no homepage at all, and they are not misdirected by
homepage being http://www.gentoo.org/ or something.

>> - users can check the metadata much more easily by just opening the xml
>>   file or interfacing to that rather than having to skim through the
>>   ebuild, the xml files are probably more user readable then ebuilds
>>   using multiple eclasses;
>
> Haven't we already agreed that accessing ebuilds/... directly is
> broken by design?

For a software sure, but as an user I am automatically brought to just
look at the files if I'm looking for the homepage of a package I know,
and seeing a metadata.xml file I'm more likely to look at that rather
than the metadata cache in /var/db/... .

And it's certainly more user-readable an XML file than HOMEPAGE with
depend-like syntax for labels and conditionals and whatever else seems
like Alec is proposing for EAPI=3

>> - webapps like packages.gentoo.org would be able to display basic
>>   information without having to parse the ebuilds or the metadata cache.
>
> Except for the ebuilds which still use the old format (that is 100% of
> the tree right now)

This of course is meant as "whenever this is fully implemented"

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[James Cloos]

>>>>> "Diego" == Diego 'Flameeyes' Pettenò <flameeyes@gmail.com> 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> package (say kde-base/kde or kde-meta) and just there? Having each
Diego> mini-package express itself as having that as its homepage is not very
Diego> useful to me, but I guess it's debatable.

Searching is an important reason for every package to specify its homepage.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

James Cloos <cloos@jhcloos.com> 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.org/ as its homepage is kinda pointless
if you think about search, since that's not data, it's noise.

Which only adds to my point.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Marius Mauch]

On Wed, 03 Dec 2008 02:05:31 +0100
flameeyes@gmail.com (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
> pointless if you think about search, since that's not data, it's
> noise.

So you're saying if I'm interested in a url to look for information
about kalarm, I should search for it in metadata.xml of random kde
packages? Sorry, but that doesn't make any sense to me.

While I'm not necessarily against your primary goal here, your
argumentation is very subjective to say the least (e.g. just because
you find xml easier to read/parse than ebuilds doesn't mean the same
holds true for everyone else, ignoring the whole cache issue). It
feels a bit like you're looking for problems to justify your solution
rather than the other way round.

Marius

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[James Cloos]

>>>>> "Jan" == Jan Kundrát <jkt@gentoo.org> 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, openeing
every metadata.xml file during update-eix is in no way acceptable.

For eix above, of course, read your favourite query tool.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

On Mon, 01 Dec 2008 00:12:23 +0100
flameeyes@gmail.com (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 "no way of handling generated homepages, use conditional
homepages, per version homepages or common homepages".

> - allows proper handling of packages lacking a HOMEPAGE;

Uh, we can do that using in-ebuild HOMEPAGE too. Just need to decide on
a convention.

> - less data in metadata cache;

Entirely a non-issue. Heck, we want more in there, not less. 

> - users can check the metadata much more easily by just opening the
> xml file or interfacing to that rather than having to skim through the
>   ebuild, the xml files are probably more user readable then ebuilds
>   using multiple eclasses;

...or they can just use a decent too. Try 'paludis --query' for an
example.

> - displaying info about the package does not require parsing the full
>   ebuild file, with its eclasses;

Uhm. It doesn't anyway, because of the metadata cache.

> - extensible to provide more links than just the homepage (forums,
>   trackers, gentoo-specific documentation, ...);

So's HOMEPAGE. You could extend the syntax to allow annotations:

HOMEPAGE="
    http://example.com/
    http://forums.example.com/ [[ role = forums ]]
    http://www.gentoo.org/example [[ role = [ Gentoo specific docs ] ]]
    gtk+? ( http://gui.example.com/ [[ role = [ Optional GUI docs ] ]]
    "

> - if we also move DESCRIPTION, search software can ignore everything
>   about ebuild parsing, and just use the metadata.xml files;
> considering how many people actually use or used eix, it would make
> sense to allow third-party applications to be able to search through
> the tree;

Except that any decent search client needs to be aware of masks,
visibility and so on anyway.

> - webapps like packages.gentoo.org would be able to display basic
>   information without having to parse the ebuilds or the metadata
> cache.

But they already display complex information.

> - as much as people might think metadata is easier to parse than
>   anything, XML has one huge advantage: there are plently of parsers
> for any language without having to actually write one, even as easy
> as it can be, and it's easily interfaced with anything; I wrote a
> simple XSL file that outputs the basic metadata details for packages
> without having any parser or executable code but xsltproc (or any
> other XSLT software), correlating data with herds.xml too;

...or you could use a proper ebuild-aware tool that displays metadata
details, including things like visibility. Again, paludis --query.

> - it really is metadata, and it makes very little sense to need
> parsing of eclasses and EAPI handling to get some data from a package
> that is non-functional in nature and free form (just like
> DESCRIPTION, and unlike LICENSE like Alec said), and that changes at
> worse once each slot (unlike LICENSE that can change at any given
> version).

It isn't non-functional.

> And the fact that you can ask the package manager for something is
> for me not a valid reason to avoi moving something in a more
> approchable place for other software.

"More approachable" is a decent package manager API. If you had that
you wouldn't need to mess around with XML APIs.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Alec Warner]

On Sun, Nov 30, 2008 at 3:12 PM, Diego 'Flameeyes' Pettenò
<flameeyes@gmail.com> wrote:
> "Alec Warner" <antarus@gentoo.org> 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, like Java;
> - allows proper handling of packages lacking a HOMEPAGE;
> - less data in metadata cache;
> - users can check the metadata much more easily by just opening the xml
>  file or interfacing to that rather than having to skim through the
>  ebuild, the xml files are probably more user readable then ebuilds
>  using multiple eclasses;
> - displaying info about the package does not require parsing the full
>  ebuild file, with its eclasses;
> - extensible to provide more links than just the homepage (forums,
>  trackers, gentoo-specific documentation, ...);
> - if we also move DESCRIPTION, search software can ignore everything
>  about ebuild parsing, and just use the metadata.xml files; considering
>  how many people actually use or used eix, it would make sense to allow
>  third-party applications to be able to search through the tree;
> - webapps like packages.gentoo.org would be able to display basic
>  information without having to parse the ebuilds or the metadata cache.
> - as much as people might think metadata is easier to parse than
>  anything, XML has one huge advantage: there are plently of parsers for
>  any language without having to actually write one, even as easy as it
>  can be, and it's easily interfaced with anything; I wrote a simple XSL
>  file that outputs the basic metadata details for packages without
>  having any parser or executable code but xsltproc (or any other XSLT
>  software), correlating data with herds.xml too;
> - it really is metadata, and it makes very little sense to need parsing
>  of eclasses and EAPI handling to get some data from a package that is
>  non-functional in nature and free form (just like DESCRIPTION, and
>  unlike LICENSE like Alec said), and that changes at worse once each
>  slot (unlike LICENSE that can change at any given version).
>
> Disadvantages:
>
> - it requires user-interface software to parse metadata.xml to show
>  data for a package; which is already needed to show per-package USE
>  flag meaning;
>
> General points:
>
> - it does not solve unrelated problems like code replication;
>
> Can someone come up with any other point beside "I don't like XML"
> (which I already said is a puny answer) and "it can theorically be 10
> different homepages for 10 different versions" (which I have sincerely
> some beef with myself since if you fork a software you might as well
> change its name)?
>
> As I said, moving out the HOMEPAGE field from a package manager
> prospective is non functional; if you're showing to the user some data
> about a package you might as well show as much as you can, like long
> descriptions, other links, and USE flags. And the fact that you can ask
> the package manager for something is for me not a valid reason to avoi
> moving something in a more approchable place for other software.

Ciaran covered most of my points already.

Third party programs should not parse ebuilds and eclasses by hand.
I'd expect half of them to get it wrong if they tried.
Ebuild parsing is hard, that is why we have three complex software
packages that for the most part do it properly.

Why is 'ask the package manager' an invalid reason to not making
something more accessible?
How accessible must this data be?

Writing an XML parser is not accessible enough (for me), we should
just put it in plain text on the hard drive, perhaps in
"/var/cache/edb/dep/${PORTDIR}/$C/$PV"

Oh wait, we do that already[1].

So really this is where I'm confused.
If third parties are using the package manager APIs to get at this
data; the only rationale to move it out of ebuilds is:

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

Randomly looking:

cd /var/cache/edb/dep/usr/portage
grep -hR HOMEPGE | wc -m
yields 1.1million characters.  Each character is 1 byte (is that so in UTF8?)
So at best you could save the 1.2GB tree 2.2 million bytes (about 2
megs) if your scheme was (more than) 100% efficient.
The extra 1.1 million characters comes from the space freed in the
cache (since we don't cache metadata.xml).

2 megs into 1200 megs is.. ".166666%" of the tree.  As I thought, not
very compelling.

Looking at DESCRIPTION:

grep -hR DESCRIPTION | wc -m
yields ~1.5 million characters.  Nice!

So if we purge that from the cache and replace it with a (more than)
100% efficient metadata.xml solution we could save: 3 megs

3 megs saved + 2 megs saved = 5 megs saved.  5 / 1200 = .416666% of
the tree.  Still again not very compelling.

- Extra Tags.  Extending HOMEPAGE is harder than changing
metadata.xml, which I imagine is part of the reason why you proposed
it.
  It will be until EAPI3 at least until we can get the HOMEPAGE tags
in ebuilds implemented and then we have to bump affected ebuilds
  to EAPI3.

However if we drop the 'extra tags' bit then the only reason to move
the data is space, and I imagine the space savings will not be
compelling; but feel free to prove me wrong.

[1] For ebuilds that have cache entries, using the default cache
implementation for portage.

>
> --
> Diego "Flameeyes" Pettenò
> http://blog.flameeyes.eu/
>

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

"Alec Warner" <antarus@gentoo.org> 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 you might have brought across since
after this I feel like you were trying to put words in my mouth.

Beside, if you really want to go down that road you should be counting
that beside ReiserFS with tail, I don't remember any other Linux FS that
has block smaller than 512bytes, which means that each file in metadata
cache is taking up much more than just its size in characters.

All your math is thus wrong.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Alec Warner]

On Mon, Dec 1, 2008 at 12:24 AM, Diego 'Flameeyes' Pettenò
<flameeyes@gmail.com> wrote:
> "Alec Warner" <antarus@gentoo.org> 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 you might have brought across since
> after this I feel like you were trying to put words in my mouth.

Sorry for that, I never meant to imply that you said space savings.

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.

>
> Beside, if you really want to go down that road you should be counting
> that beside ReiserFS with tail, I don't remember any other Linux FS that
> has block smaller than 512bytes, which means that each file in metadata
> cache is taking up much more than just its size in characters.
>
> All your math is thus wrong.

As was pointed out on IRC, UTF8 characters are not a fixed size,
making my math even more wrong ;)

>
> --
> Diego "Flameeyes" Pettenò
> http://blog.flameeyes.eu/
>

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

"Alec Warner" <antarus@gentoo.org> 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 point in requiring using of a
specific API when the same data can easily be available in a format that
is more or less parsable with ease in any modern (and non) programming
language.

Beside, I find expanding the HOMEPAGE syntax to allow more than one link
a bit ... overkill, if the same thing can be achieved in metadata.xml...

>> Beside, if you really want to go down that road you should be counting
>> that beside ReiserFS with tail, I don't remember any other Linux FS that
>> has block smaller than 512bytes, which means that each file in metadata
>> cache is taking up much more than just its size in characters.
>>
>> All your math is thus wrong.
>
> As was pointed out on IRC, UTF8 characters are not a fixed size,
> making my math even more wrong ;)

If we consider HOMEPAGE, the assumption that characters are fixed size
to 1 byte is good enough; URLs are usually encoded in pure ascii
character space for compatibility; while IDN would break that
assumption, we can't even assume that IDN is always available and so on.

For description maybe it's different because there is space there for
UTF-8 characters, but that's going to bring us even farthest than the
point.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Mon, 01 Dec 2008 10:00:33 +0100
flameeyes@gmail.com (Diego 'Flameeyes' Pettenò) wrote:

> "Alec Warner" <antarus@gentoo.org> 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 point in requiring using of a
> specific API when the same data can easily be available in a format
> that is more or less parsable with ease in any modern (and non)
> programming language.
> 
> Beside, I find expanding the HOMEPAGE syntax to allow more than one
> link a bit ... overkill, if the same thing can be achieved in
> metadata.xml...

I find moving HOMEPAGE out of ebuilds to be a bit overkill.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Steve Dibb]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252; format=flowed, Size: 624 bytes --]

Peter Volkov wrote:
> В Вск, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:
>> In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
>> Does someone have an example where older versions stay at an old homepage
>> and newer versions moved to a new homepage?
> 
> Yes. This is quite a common case when one upstream stopped development
> of the package and new developer took it. traceroute, flow-tools are
> just examples from the top of my head. I remember I saw more such
> things...

Add libdvdread to the list.  Same as others, newer version is a forked one.

Steve

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Tomáš Chvátal]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
> 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 would rather see something like:

packagename/metadata.xml
packagename/package-base.ebuild
packagename/packagename-version.ebuild
packagename/Manifest
packagename/Changelog

Where package-base would store everything basic for the ebuild, licences and 
so on, and in package-version would be only specific changes for the version 
(for example patching Makefile).

Variables will be overridable this way and thus i think it would be nicer.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Serkan Kaba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomáš Chvátal yazmış:
> On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
>> 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 would rather see something like:
> 
> packagename/metadata.xml
> packagename/package-base.ebuild
I've been thinking of something like this for a long time. It would
greatly improve maintanance (we could put some common ebuild logic
there,too) and reduce the tree size.
> packagename/packagename-version.ebuild
> packagename/Manifest
> packagename/Changelog
> 
> Where package-base would store everything basic for the ebuild, licences and 
> so on, and in package-version would be only specific changes for the version 
> (for example patching Makefile).
> 
> Variables will be overridable this way and thus i think it would be nicer.
> 

- --
Sincerely,
Serkan KABA
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkymmIACgkQRh6X64ivZaKaNQCfYT0Db8zjcIYkzZcPPn83IxMM
UIgAniA8kdc511KJ9eaDNwp8YR7CqKkf
=JcT+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
> > 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 would rather see something like:
> 
> packagename/metadata.xml
> packagename/package-base.ebuild
> packagename/packagename-version.ebuild
> packagename/Manifest
> packagename/Changelog

Correct me if i'm wrong, but this doesn't address the problem with
multiple versions having multiple homepages.
I'm with Diego here that this should be *very* rare.

Can somebody verify this? I mean just throw a little shell script on the
portage tree showing which ebuilds differ in HOMEPAGE but still have the
same path.. my poor ibook would take too long for such a thing, so
sorry, no data here.

And while your proposal sounds more compliant to the DRY principle, i
would object it on the basis that it makes a single ebuild actually
harder to understand as you have to read (1) eclasses, (2) -base.ebuild
and (3) -version.ebuild.
-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

Matti Bickel wrote:
> And while your proposal sounds more compliant to the DRY principle, i
> would object it on the basis that it makes a single ebuild actually
> harder to understand as you have to read (1) eclasses, (2) -base.ebuild
> and (3) -version.ebuild.

That's quite exactly what I wanted to write - plus this -base.ebuild
thingy would only make sense if we also allow versioning of
-base.ebuilds. And then we're quickly speaking of package-based eclasses
instead of "-base.ebuilds".

If we're speaking of a list of whishes for 2009 - i'd prefer to see
eclass versioning instead of -base.ebuilds ;)

  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Sun, 30 Nov 2008 14:46:39 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> I would rather see something like:
> 
> packagename/metadata.xml
> packagename/package-base.ebuild
> packagename/packagename-version.ebuild
> packagename/Manifest
> packagename/Changelog

All this really needs is per-package eclasses.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

flameeyes@gmail.com (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, for the future EAPI, the
problem of what to do with missing HOMEPAGE. We still have to find a
solution for that on the EAPI 0, 1 and 2 though since it's a bit of a
big problem when we point to domain squatters.

If it was feasible to just make missing HOMEPAGE a softfail for the
other three it would be even better.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Sun, Nov 30, 2008 at 02:23:48PM +0100, Diego 'Flameeyes' Pettenò wrote:
> Please submit all comments, as long as they are not "I don't like XML"
> or "XML is the wrong answer" and similar since the point here is not to
> discuss the format of metadata but rather where to have it.

XML is the wrong answer. Sorry, but in this case, I'm arguing that this
should not be in metadata.xml but in,say, a per-package eclass. Also,
you don't have to worry about different HOMEPAGE's for different
versions/slots because you get that for free as soon as you decide to
use per-package/per-category eclasses. Really, we might as well use
per-package eclasses for this(not to mention the fact that they are
useful in other cases.)

Regards,
Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 783 bytes --]

On Sun, 30 Nov 2008 14:23:48 +0100
flameeyes@gmail.com (Diego 'Flameeyes' Pettenò) wrote:
> This makes it easier to get the package's homepage for submitting bugs
> upstream (you just do a single lookup for the metadata.xml file rather
> than checking the ebuild

...or you have a tool that uses the package manager API to show you the
homepage of the package in the current directory. I've attached a small
script that'll do that for you -- much easier than trying to dig your
way through an XML file.

> It also makes searching by homepage easier (a search program would
> take much less time to parse XML that an ebuild).

Search programs don't parse ebuilds. They parse the metadata cache,
which is an awful lot easier to parse than XML.

-- 
Ciaran McCreesh

[-- Attachment #1.2: show_homepage.rb --]
[-- Type: application/x-ruby, Size: 1306 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Santiago M. Mola]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

El dom, 30-11-2008 a las 14:23 +0100, Diego 'Flameeyes' Pettenò
escribió:
> 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?
> 

> 
> Please submit all comments, as long as they are not "I don't like XML"
> or "XML is the wrong answer" and similar since the point here is not to
> discuss the format of metadata but rather where to have it.

As suggested by Ciaran and Serkan, this could also be achieved with
per-package eclasses [1].

That way, it would be easy to avoid duplication of not only HOMEPAGE but
also SRC_URI, LICENSE, or any other part of an ebuild.

In fact, this idea is already being used in the tree in the form of bash
scripts in ${FILESDIR} that are source'd in the ebuild [2].

[1] https://bugs.gentoo.org/show_bug.cgi?id=69714
[2]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldwind@gmail.com | GPG: AAD203B5

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Peter Volkov]

В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет:
> per-package eclasses [1].
> That way, it would be easy to avoid duplication of not only HOMEPAGE but
> also SRC_URI, LICENSE, or any other part of an ebuild.

Having per-package eclasses (PPE) just to set common HOMEPAGE is
definitely overkill. What other reasons for PPE to exist?

If you want to separate common code, then PPE is very dangerous.

Take for example ebuilds which share same src_*() function which you had
to modify a bit with version bump. To be absolutely sure that you have
not broke anything you'll have to check all versions of the package or
there are chances that you broke stable tree and have not noticed that.
Of course the same stands for eclasses. The difference between PPE and
global eclasses is that 1. PPE covers less packages and it'll take
longer to notice that error 2. per-package things are changing more
rapidly and thus more changes to PPE will be required. All this means
that we'll have more breakages. So what are the benefits to overbalance
this minuses?

-- 
Peter.

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

On Sun, 30 Nov 2008 19:50:17 +0300
Peter Volkov <pva@gentoo.org> wrote:
> В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет:
> > per-package eclasses [1].
> > That way, it would be easy to avoid duplication of not only
> > HOMEPAGE but also SRC_URI, LICENSE, or any other part of an ebuild.
> 
> Having per-package eclasses (PPE) just to set common HOMEPAGE is
> definitely overkill. What other reasons for PPE to exist?

In an awful lot of cases, there's a very high degree of code overlap
between ebuild versions.

> If you want to separate common code, then PPE is very dangerous.
> 
> Take for example ebuilds which share same src_*() function which you
> had to modify a bit with version bump. To be absolutely sure that you
> have not broke anything you'll have to check all versions of the
> package or there are chances that you broke stable tree and have not
> noticed that. Of course the same stands for eclasses. The difference
> between PPE and global eclasses is that 1. PPE covers less packages
> and it'll take longer to notice that error 2. per-package things are
> changing more rapidly and thus more changes to PPE will be required.
> All this means that we'll have more breakages. So what are the
> benefits to overbalance this minuses?

You appear to be assuming that Gentoo developers are careless and
incompetent. The ebuild format already gives developers more than
enough rope to hang themselves and every single user -- per package
eclasses don't alter this in any way.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Peter Volkov]

В Вск, 30/11/2008 в 16:54 +0000, Ciaran McCreesh пишет:
> On Sun, 30 Nov 2008 19:50:17 +0300
> Peter Volkov <pva@gentoo.org> wrote:
> > В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет:
> > > per-package eclasses [1].
> > > That way, it would be easy to avoid duplication of not only
> > > HOMEPAGE but also SRC_URI, LICENSE, or any other part of an ebuild.
> > 
> > Having per-package eclasses (PPE) just to set common HOMEPAGE is
> > definitely overkill. What other reasons for PPE to exist?
> 
> In an awful lot of cases, there's a very high degree of code overlap
> between ebuild versions.

So? Is size a big problem? If not then again what problem are you trying
to solve?

Don't mix good programming practice of with good ebuild maintenance
practice. They are solving different problems and that's why they are
different.

Commited ebuild corresponds to the package of some version. It was
written, tested and released (commited). Now never touch it without real
necessity even indirectly through PPE. If you wish to improve package do
that in ~arch tree.

If you wish to make ebuilds writing closer to the programming practice
then yes! There is similarity: being a good upstream you never touch
already released tarbals.

And yes. we still have eclasses but they are exceptions and that is why
we have exceptional rule for handling them: review on -dev before
commit. Should we have same rule for PPE?


> > If you want to separate common code, then PPE is very dangerous.
> > 
> > Take for example ebuilds which share same src_*() function which you
> > had to modify a bit with version bump. To be absolutely sure that you
> > have not broke anything you'll have to check all versions of the
> > package or there are chances that you broke stable tree and have not
> > noticed that. Of course the same stands for eclasses. The difference
> > between PPE and global eclasses is that 1. PPE covers less packages
> > and it'll take longer to notice that error 2. per-package things are
> > changing more rapidly and thus more changes to PPE will be required.
> > All this means that we'll have more breakages. So what are the
> > benefits to overbalance this minuses?
> 
> You appear to be assuming that Gentoo developers are careless and
> incompetent. The ebuild format already gives developers more than
> enough rope to hang themselves and every single user -- per package
> eclasses don't alter this in any way.

Nope, I assume we are all humans and even careful people do mistakes. If
package works do not to touch it.

-- 
Peter.

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

On Sun, 30 Nov 2008 21:07:00 +0300
Peter Volkov <pva@gentoo.org> wrote:
> > In an awful lot of cases, there's a very high degree of code overlap
> > between ebuild versions.
> 
> So? Is size a big problem? If not then again what problem are you
> trying to solve?

Code duplication is a big problem.

> Commited ebuild corresponds to the package of some version. It was
> written, tested and released (commited). Now never touch it without
> real necessity even indirectly through PPE. If you wish to improve
> package do that in ~arch tree.
> 
> If you wish to make ebuilds writing closer to the programming practice
> then yes! There is similarity: being a good upstream you never touch
> already released tarbals.

You're under the mistaken impression that people will go back and
retroactively change existing ebuilds. This won't happen -- if nothing
else, because it's an EAPI bump.

> And yes. we still have eclasses but they are exceptions and that is
> why we have exceptional rule for handling them: review on -dev before
> commit. Should we have same rule for PPE?

Really, I'd like to see *every* non-trivial new ebuild or major change
on bumps reviewed. But that's not going to happen...

> > You appear to be assuming that Gentoo developers are careless and
> > incompetent. The ebuild format already gives developers more than
> > enough rope to hang themselves and every single user -- per package
> > eclasses don't alter this in any way.
> 
> Nope, I assume we are all humans and even careful people do mistakes.
> If package works do not to touch it.

We're talking for new packages, not for retroactively going and making
everything in the tree EAPI 3.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Joe Peterson]

Diego 'Flameeyes' Pettenò wrote:
> 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?

For that matter, whatever is decided, why not include "DESCRIPTION"?
This seems to me a candidate for something that does not change version
to version (or at least shouldn't - since there is only one displayed,
e.g., in emerge --search).

						-Joe

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[James Cloos]

If it does move to metadata, it will need to be copied into /var/db on
install.  It is important information which should not be lost if the
package is ever removed from portage.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ulrich Mueller]

>>>>> On Sun, 30 Nov 2008, James Cloos wrote:

> If it does move to metadata, it will need to be copied into /var/db
> on install.  It is important information which should not be lost if
> the package is ever removed from portage.

Also, a scan shows that there are about 400 ebuilds in the tree that
access the ${HOMEPAGE} variable. For example, it is used to output
messages in fetch-restricted packages.

Ulrich

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

While the KDE eclass doesn't set specific homepages per packages, a
number of other eclasses do:

eclass/horde.eclass:HOMEPAGE="http://www.horde.org/${HORDE_PN}"
eclass/java-pkg-2.eclass:	HOMEPAGE="http://commons.apache.org/${PN#commons-}/"
eclass/kernel-2.eclass:HOMEPAGE="http://www.kernel.org/ http://www.gentoo.org/ ${HOMEPAGE}"
eclass/perl-module.eclass:	HOMEPAGE="http://search.cpan.org/search?query=${MY_PN:-${PN}}&mode=dist"
eclass/php-ext-pecl-r1.eclass:HOMEPAGE="http://pecl.php.net/${PECL_PKG}"
eclass/php-pear-r1.eclass:[[ -z "${HOMEPAGE}" ]] && HOMEPAGE="http://pear.php.net/${PHP_PEAR_PKG_NAME}"
eclass/ruby.eclass:HOMEPAGE="http://raa.ruby-lang.org/list.rhtml?name=${PN}"
eclass/xfce44.eclass:	HOMEPAGE="http://thunar.xfce.org/pwiki/projects/${MY_PN}"

Additionally, some of the above eclasses are used by other eclasses: ant-tasks,
java-gnome, perl-app, perl-post, php-ext-pecl, php-ezc, php-pear, gems

A quick scan of the tree shows 15% of the ebuilds do not set the HOMEPAGE
variable in the ebuild itself. And a LOT more qualify, esp. in dev-ruby and
dev-perl. Some quick scanning on groups of packages that I'm aware of puts the
figure beyond 20% of the tree qualifying (converting any dev-perl/perl-core
package that comes from CPAN).

As another major pain, for ebuilds where the homepage changes every version in
some predictable pattern, you have now increased the maintenance burden. Before
we could just copy the ebuild if we had a suitable variable expression in the
HOMEPAGE variable, but now we'd have to edit it into metadata.xml as well.

For all the rest of the ebuilds where it does remain static, I don't see
any actual advantage to removing it from the ebuilds.

To be very clear however, I've got _zero_ objections to adding the extra
new fields into the metadata.xml, provided they are version independent.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Le mardi 02 décembre 2008 à 16:50 -0800, Robin H. Johnson a écrit :
> As another major pain, for ebuilds where the homepage changes every
> version in
> some predictable pattern, you have now increased the maintenance
> burden. Before
> we could just copy the ebuild if we had a suitable variable expression
> in the
> HOMEPAGE variable, but now we'd have to edit it into metadata.xml as
> well.
> 

actually I thought it was strictly forbidden to put any kind of variable
in the HOMEPAGE value. Did I miss something, is it an old restriction
that doesn't matter anymore ?

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Thu, Dec 04, 2008 at 12:31:44AM +0100, Gilles Dartiguelongue wrote:
> Le mardi 02 décembre 2008 à 16:50 -0800, Robin H. Johnson a écrit :
> > As another major pain, for ebuilds where the homepage changes every
> > version in
> > some predictable pattern, you have now increased the maintenance
> > burden. Before
> > we could just copy the ebuild if we had a suitable variable expression
> > in the
> > HOMEPAGE variable, but now we'd have to edit it into metadata.xml as
> > well.
> actually I thought it was strictly forbidden to put any kind of variable
> in the HOMEPAGE value. Did I miss something, is it an old restriction
> that doesn't matter anymore ?
It exists as a warning in some places still I think.

perl-module.eclass has this:
[ -z "${HOMEPAGE}" ] && \
	HOMEPAGE="http://search.cpan.org/search?query=${MY_PN:-${PN}}&mode=dist"

There was something else that used the form of:
MY_PV=$(something-from-versionator ...)
MY_PN=...
HOMEPAGE="http://foobar/${MY_PN}/${MY_PV}"

I'm pretty sure I saw something about one of the EAPIs supporting
USE-dependency stuff in HOMEPAGE as well.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Wed, 3 Dec 2008 14:18:59 -0800
"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> I'm pretty sure I saw something about one of the EAPIs supporting
> USE-dependency stuff in HOMEPAGE as well.

Use-conditional dependency, not use dependency.

Use-conditional dependencies are this:

    flag? ( whatever )

Use dependencies are this:

    foo/bar[flag]

Much confusion arises if the distinction isn't made.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

On Thu, 04 Dec 2008 00:31:44 +0100
Gilles Dartiguelongue <eva@gentoo.org> wrote:
> actually I thought it was strictly forbidden to put any kind of
> variable in the HOMEPAGE value. Did I miss something, is it an old
> restriction that doesn't matter anymore ?

A few developers who don't use tools properly don't like it because it
stops them clipboarding it. The solution, of course, is to do it lots
so those people have to learn to do things the right way.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]