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
30 matches
Mail list logo
