Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
On Wed, 3 Dec 2008 14:18:59 -0800 "Robin H. Johnson" <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpr4oXdXnWQ1.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
On Thu, 04 Dec 2008 00:31:44 +0100 Gilles Dartiguelongue <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 <[EMAIL PROTECTED]> Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgp24EsyRaSjN.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
> 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
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 <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
On Sun, Nov 30, 2008 at 8:53 AM, Peter Volkov <[EMAIL PROTECTED]> 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. > > >
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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
On Sun, 30 Nov 2008 21:07:00 +0300 Peter Volkov <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
В Вск, 30/11/2008 в 16:54 +, Ciaran McCreesh пишет: > On Sun, 30 Nov 2008 19:50:17 +0300 > Peter Volkov <[EMAIL PROTECTED]> 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
On Sun, 30 Nov 2008 19:50:17 +0300 Peter Volkov <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
В Вск, 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
В Вск, 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
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
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: [EMAIL PROTECTED] | GPG: AAD203B5
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
-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
В Вск, 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
On Sun, 30 Nov 2008 14:23:48 +0100 [EMAIL PROTECTED] (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 show_homepage.rb Description: application/ruby signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 pgp1XA7WdbcXk.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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
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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
On Sun, 30 Nov 2008 14:46:39 +0100 Tomáš Chvátal <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
Tomáš Chvátal <[EMAIL PROTECTED]> 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) pgpLZ47VAfi0Y.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
-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:
> http://package.oldbarfoo.org
> 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
-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
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: http://package.oldbarfoo.org 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
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: http://package.foobar.com http://package.foobar.com/bugs and for gentoo-specific http://www.gentoo.org/proj/en/foo/foobar http://www.gentoo.org/doc/en/foobar.xml 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/ pgpKz8EqcCHvB.pgp Description: PGP signature
