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? ( whate
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
>
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 tool
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 ex
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.kerne
> 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 th
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
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 impr
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
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 probl
В Вск, 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
> > >
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.
В Вск, 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 informa
В Вск, 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 overk
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 "DESCRIPTIO
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 al
-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 ne
В Вск, 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
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 p
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 wro
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 H
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
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
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-pack
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
-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
-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
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
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 l
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
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 l
31 matches
Mail list logo
