[gentoo-dev] RDEPENDing on packages from overlays?

[gentoo-dev] RDEPENDing on packages from overlays?

[Eray Aslan]

https://bugs.gentoo.org/show_bug.cgi?id=364445
https://bugs.gentoo.org/show_bug.cgi?id=364401

Basically, there are requests to add packages to RDEPEND in virtual/mda
and virtual/mta that are not in the official tree but in sunrise.

On one side, *DEPENDing on a package outside the tree doesn't seem
right.  Additionally, keeping track of all the overlays and their
package versions, USE flags and flag changes are potentially too much to
track.  We will be making changes to a virtual package without testing
whether it works.

On the other hand, we are making life (unneccesarily?) difficult for
overlay users by not incorporating the requested changes to the official
tree.

Comments on how to proceed?  Is it OK for a virtual to list a package
which is in an overlay in RDEPEND?

-- 
Eray Aslan
Developer, Gentoo Linux       eras <at> gentoo.org

[gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Chí-Thanh Christopher Nguyễn]

Eray Aslan schrieb:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
>
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right.

I understand that the push to remove old-style virtuals from the main
tree is because they cause headaches for the package managers during
dependency calculation. I also understand that existing EAPIs will not
be amended to forbid old-style virtuals.

Would it make sense to do the following:
(1) make all new-style virtuals additionally depend on an old-style
virtual (a new category might be appropriate)
(2) ebuilds in overlays can PROVIDE the old-style virtual
(3) in a future EAPI, package managers are allowed to ignore the
old-style virtual dependency for packages which are not already installed

If directly including installed old-style virtual packages in the
dependency calculations is not feasible, (3) could be implemented
through modifying package.provided like it is already done for
package.{keywords,mask,use} after profile/ updates


Regards,
Chi-Thanh Christopher Nguyen

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Zac Medico]

On 04/23/2011 03:28 AM, Chí-Thanh Christopher Nguyễn wrote:
> Eray Aslan schrieb:
>> https://bugs.gentoo.org/show_bug.cgi?id=364445
>> https://bugs.gentoo.org/show_bug.cgi?id=364401
>>
>> Basically, there are requests to add packages to RDEPEND in virtual/mda
>> and virtual/mta that are not in the official tree but in sunrise.
>>
>> On one side, *DEPENDing on a package outside the tree doesn't seem
>> right.
> 
> I understand that the push to remove old-style virtuals from the main
> tree is because they cause headaches for the package managers during
> dependency calculation. I also understand that existing EAPIs will not
> be amended to forbid old-style virtuals.
> 
> Would it make sense to do the following:
> (1) make all new-style virtuals additionally depend on an old-style
> virtual (a new category might be appropriate)
> (2) ebuilds in overlays can PROVIDE the old-style virtual

It seems like new-style virtual would be introducing complexity without
adding any value here. Why not just use a pure old-style virtual?

> (3) in a future EAPI, package managers are allowed to ignore the
> old-style virtual dependency for packages which are not already installed

I'm not sure what you mean here. In || dependencies, it's normal to
ignore choices that are masked or unavailable, so I'm not sure that
you're suggesting anything different from the existing || behavior.

> If directly including installed old-style virtual packages in the
> dependency calculations is not feasible, (3) could be implemented
> through modifying package.provided like it is already done for
> package.{keywords,mask,use} after profile/ updates

Again, I'm not sure that I understand the point of this. Since ||
dependencies already ignore unavailable or masked choices, why would
package.provided be needed?
-- 
Thanks,
Zac

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Chí-Thanh Christopher Nguyễn]

Zac Medico schrieb:
>> Would it make sense to do the following:
>> (1) make all new-style virtuals additionally depend on an old-style
>> virtual (a new category might be appropriate)
>> (2) ebuilds in overlays can PROVIDE the old-style virtual
>>     
> It seems like new-style virtual would be introducing complexity without
> adding any value here. Why not just use a pure old-style virtual?
>   

The idea is that code for old-style virtuals can be removed from the
package manager (which seems to be one of the goals of getting rid of
old-style virtuals).

>> (3) in a future EAPI, package managers are allowed to ignore the
>> old-style virtual dependency for packages which are not already installed
>>     
> I'm not sure what you mean here. In || dependencies, it's normal to
> ignore choices that are masked or unavailable, so I'm not sure that
> you're suggesting anything different from the existing || behavior.
>   

Indeed, the old-style virtual will be a non-existing package in the case
of a package manager which doesn't support them.

>> If directly including installed old-style virtual packages in the
>> dependency calculations is not feasible, (3) could be implemented
>> through modifying package.provided like it is already done for
>> package.{keywords,mask,use} after profile/ updates
>>     
> Again, I'm not sure that I understand the point of this. Since ||
> dependencies already ignore unavailable or masked choices, why would
> package.provided be needed?
>   

Because the package manager might not know about old-style virtuals
during dependency calculation.


Regards,
Chi-Thanh Christopher Nguyen

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Ciaran McCreesh]

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

On Sat, 23 Apr 2011 12:28:29 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> Would it make sense to do the following:
> (1) make all new-style virtuals additionally depend on an old-style
> virtual (a new category might be appropriate)

No.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 12:28:29 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>   
>> Would it make sense to do the following:
>> (1) make all new-style virtuals additionally depend on an old-style
>> virtual (a new category might be appropriate)
>>     
> No.
>   

Because there is a reason for not doing so, or because you think that
multi-repository support is a superior solution which will come sooner?


Regards,
Chi-Thanh Christopher Nguyen

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Ciaran McCreesh]

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

On Sat, 23 Apr 2011 15:28:04 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> Because there is a reason for not doing so, or because you think that
> multi-repository support is a superior solution which will come
> sooner?

Because what you propose solves nothing, and prevents the entire point
of the exercise, which is to do away entirely with old style virtuals
and all the problems they introduce.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 15:28:04 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>   
>> Because there is a reason for not doing so, or because you think that
>> multi-repository support is a superior solution which will come
>> sooner?
>>     
> Because what you propose solves nothing, and prevents the entire point
> of the exercise, which is to do away entirely with old style virtuals
> and all the problems they introduce.
>   

What I propose solves the problems that old-style virtuals introduce in
dependency resolution. What other problems do they cause?


Regards,
Chi-Thanh Christopher Nguyen

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Ciaran McCreesh]

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

On Sat, 23 Apr 2011 16:47:37 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> What I propose solves the problems that old-style virtuals introduce
> in dependency resolution.

Not really, because it means we'd have to keep the nasty old code around
forever. If we just do away with the things entirely instead then we
can pretend they never existed (like we did for ? : dependencies).

> What other problems do they cause?

DEPEND=">=virtual/blah-2"

DEPEND="virtual/blah[foo]"

DEPEND="!virtual/that-i-provide"

PROVIDE="not-a/virtual"

best_version virtual/blah

The full VDB load required to figure out whether or not a virtual is
installed.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] reconciling new-style virtuals with overlays

[Ulrich Mueller]

>>>>> On Sat, 23 Apr 2011, Ciaran McCreesh wrote:

> On Sat, 23 Apr 2011 16:47:37 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>> What I propose solves the problems that old-style virtuals
>> introduce in dependency resolution. What other problems do they
>> cause?

> DEPEND=">=virtual/blah-2"

> DEPEND="virtual/blah[foo]"

> DEPEND="!virtual/that-i-provide"

> PROVIDE="not-a/virtual"

> best_version virtual/blah

> The full VDB load required to figure out whether or not a virtual is
> installed.

Apart from these, information for old-style virtuals is decentralised:
It's scattered over all packages providing the virtual, plus several
virtuals files in profiles (in January, we had about 60 such files).

Obviously it's difficult to keep track of this. When going through the
remaining old-style virtuals, I've found examples for all of the
following:

- virtual provided by packages but not listed in profiles
- virtual listed in profiles but not provided by any package
- virtuals file in profiles listing a preferred package that doesn't
  provide the virtual
- versioned package atoms for virtuals in profiles
- virtual removed long time ago, but some packages still containing
  forgotten PROVIDE lines and blockers
- virtual listed in profiles, but was converted to new-style long ago

Besides, if you look at the history of profiles/base/virtuals, you'll
see that the last old-style virtuals were added in 2006. I take this
as an indication that there's no real need for them.

Ulrich

Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 16:47:37 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>   
>> What I propose solves the problems that old-style virtuals introduce
>> in dependency resolution.
>>     
> Not really, because it means we'd have to keep the nasty old code around
> forever. If we just do away with the things entirely instead then we
> can pretend they never existed (like we did for ? : dependencies).
>   

We can mostly pretend that they never existed. PROVIDE will only be
relevant during the installation phase.

>> What other problems do they cause?
>>     
> DEPEND=">=virtual/blah-2"
>
> DEPEND="virtual/blah[foo]"
>
> DEPEND="!virtual/that-i-provide"
>
> PROVIDE="not-a/virtual"
>   
Would be ignored during dependency calculation and become
not-a/virtual-<version> in package.provided later.
> best_version virtual/blah
>
> The full VDB load required to figure out whether or not a virtual is
> installed

Problems I had indeed not taken into account are !virtual/foo
dependencies and USE flags in package.provided (not allowed yet, bug
142941). But the former are also not going to work any more if new-style
virtuals are used instead of old-style, as you block only the virtuals
and not their providers.

If the USE flag problem is considered a show-stopper, then I have to
take back my proposal until bug 142941 is fixed.


Regards,
Chi-Thanh Christopher Nguyen

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Zac Medico]

On 04/22/2011 11:05 PM, Eray Aslan wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
> 
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
> 
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right.  Additionally, keeping track of all the overlays and their
> package versions, USE flags and flag changes are potentially too much to
> track.  We will be making changes to a virtual package without testing
> whether it works.

I would assume that it's the overlay maintainers' responsibility to test
and report any problems. Any such problems would should affect the
overlay users, so it shouldn't cause any regression for users who don't
choose to use the overlay.

> On the other hand, we are making life (unneccesarily?) difficult for
> overlay users by not incorporating the requested changes to the official
> tree.

I don't imagine it's that much work to maintain a fork of the virtual.
It's just an inconvenience for users since the version from the overlay
might become temporarily outdated and cause problems with dependency
resolution.

> Comments on how to proceed?

Either way is fine. It's just a matter of whether or not collaboration
with the overlay is worthy of your time.

> Is it OK for a virtual to list a package
> which is in an overlay in RDEPEND?

Yes, that's fine. For || dependencies, repoman will be satisfied as long
as there at least one provider available for a given profile.
-- 
Thanks,
Zac

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Nathan Phillip Brink]

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

On Sat, Apr 23, 2011 at 04:02:24AM -0700, Zac Medico wrote:
> On 04/22/2011 11:05 PM, Eray Aslan wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=364445
> > https://bugs.gentoo.org/show_bug.cgi?id=364401
> > 
> > Basically, there are requests to add packages to RDEPEND in virtual/mda
> > and virtual/mta that are not in the official tree but in sunrise.
> > 
> > On one side, *DEPENDing on a package outside the tree doesn't seem
> > right.  Additionally, keeping track of all the overlays and their
> > package versions, USE flags and flag changes are potentially too much to
> > track.  We will be making changes to a virtual package without testing
> > whether it works.
> 
> I would assume that it's the overlay maintainers' responsibility to test
> and report any problems. Any such problems would should affect the
> overlay users, so it shouldn't cause any regression for users who don't
> choose to use the overlay.
> 
> > On the other hand, we are making life (unneccesarily?) difficult for
> > overlay users by not incorporating the requested changes to the official
> > tree.
> 
> I don't imagine it's that much work to maintain a fork of the virtual.
> It's just an inconvenience for users since the version from the overlay
> might become temporarily outdated and cause problems with dependency
> resolution.

I would prefer that the virtual maintenance still happen in the main
tree whenever possible. In this case, the virtual's maintainer seems
willing to add the package atoms to the virtual -- the only concern
was whether or not it was allowed to *DEPEND on atoms known not to be
in gentoo-x86. So the answers I've read all add up to a "yes, go
ahead".

Encouraging overlays to maintain their own virtual replacements would
be encouraging more people who are not familiar with a particular
virtual to mess with it in their own repositories. Also, if multiple
overlays each need to add a single but different DEPEND to a
particular virtual, the user will end up with only one of these
virtual overrides. Someone who overrides a virtual in an overlay would
thus be expected to take into account other overlays which provide
candidates for that virtual. Having overlay maintainers do this would
be much more of a mess than letting one person manage the gentoo-x86
virtual and get everything done right once and without duplication of
effort.

-- 
binki

Look out for missing or extraneous apostrophes!

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Thomas Sachau]

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

Am 23.04.2011 13:02, schrieb Zac Medico:
> On 04/22/2011 11:05 PM, Eray Aslan wrote:
>> On the other hand, we are making life (unneccesarily?) difficult for
>> overlay users by not incorporating the requested changes to the official
>> tree.
> 
> I don't imagine it's that much work to maintain a fork of the virtual.
> It's just an inconvenience for users since the version from the overlay
> might become temporarily outdated and cause problems with dependency
> resolution.

It may be no issue as long as the virtual does not change that much or as long as not more than 1
overlay forks the virtual. But as already written in Bugzilla, you create an issue for users, if you
have 2 overlays added, which both provide the package. Simple example, which i presented in Bugzilla:

If e.g. kde and sunrise overlay both provide an mta, they would both need a fork of virtual/mta. Now
one of those forks will be preferred and used, e.g. the kde one. This means, that you cannot install
the mta from sunrise to satisfy the virtual without additional manual work. The only way to solve
this properly without asking the user to manually adjust things is to just add all mtas from
overlays (maybe restricted to dev-controlled or -managed overlays) to virtual/mta in the main tree.


-- 
Thomas Sachau

Gentoo Linux Developer


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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Ciaran McCreesh]

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

On Sat, 23 Apr 2011 14:07:21 +0200
Thomas Sachau <tommy@gentoo.org> wrote:
> It may be no issue as long as the virtual does not change that much
> or as long as not more than 1 overlay forks the virtual. But as
> already written in Bugzilla, you create an issue for users, if you
> have 2 overlays added, which both provide the package. Simple
> example, which i presented in Bugzilla:

That's solved by giving Portage proper multi-repository support. Wasn't
that one of last year's Summer of Code projects?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Ulrich Mueller]

>>>>> On Sat, 23 Apr 2011, Thomas Sachau wrote:

> If e.g. kde and sunrise overlay both provide an mta, they would both
> need a fork of virtual/mta. Now one of those forks will be preferred
> and used, e.g. the kde one. This means, that you cannot install the
> mta from sunrise to satisfy the virtual without additional manual
> work.

So far this is only a hypothetical example, as there is no MTA package
in the KDE overlay. As long as sunrise is the only overlay providing
such a package, I don't see how maintaining a fork of the virtual
would be problematic. Any collision scenarios can be solved when they
really arise (if ever).

> The only way to solve this properly without asking the user to
> manually adjust things is to just add all mtas from overlays (maybe
> restricted to dev-controlled or -managed overlays) to virtual/mta in
> the main tree.

The additional entries in the any-of-many dependency are not an issue.
But the problem that I see with this approach is that a maintainer of
a package depending on the virtual would have to test if his package
works with those additional dependencies from overlays. I'd rather not
impose such an additional burden upon maintainers of main tree
packages.

Ulrich

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Zac Medico]

On 04/23/2011 06:05 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 23 Apr 2011, Thomas Sachau wrote:
> 
>> If e.g. kde and sunrise overlay both provide an mta, they would both
>> need a fork of virtual/mta. Now one of those forks will be preferred
>> and used, e.g. the kde one. This means, that you cannot install the
>> mta from sunrise to satisfy the virtual without additional manual
>> work.
> 
> So far this is only a hypothetical example, as there is no MTA package
> in the KDE overlay. As long as sunrise is the only overlay providing
> such a package, I don't see how maintaining a fork of the virtual
> would be problematic. Any collision scenarios can be solved when they
> really arise (if ever).
> 
>> The only way to solve this properly without asking the user to
>> manually adjust things is to just add all mtas from overlays (maybe
>> restricted to dev-controlled or -managed overlays) to virtual/mta in
>> the main tree.
> 
> The additional entries in the any-of-many dependency are not an issue.
> But the problem that I see with this approach is that a maintainer of
> a package depending on the virtual would have to test if his package
> works with those additional dependencies from overlays. I'd rather not
> impose such an additional burden upon maintainers of main tree
> packages.

If people are going to use overlays to override the virtuals anyway,
then the net effect is practically the same. The only difference is
whether the new-style virtual is provided by the main tree or by the
overlay.
-- 
Thanks,
Zac

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Eray Aslan]

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

Replying randomly

On Sat, Apr 23, 2011 at 08:24:59AM -0700, Zac Medico wrote:

The consensus seems to be to leave it for the package maintainer to
decide.

I, for one, will be making the necessary changes to include packages
from overlays until, for whatever reason, it either

* becomes too burdensome
* hinders the main tree

Thanks for the feedback.

-- 
Eray Aslan
Developer, Gentoo Linux       eras <at> gentoo.org

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Ulrich Mueller]

>>>>> On Sun, 24 Apr 2011, Eray Aslan wrote:

> The consensus seems to be to leave it for the package maintainer to
> decide.

> I, for one, will be making the necessary changes to include packages
> from overlays until, for whatever reason, it either

> * becomes too burdensome
> * hinders the main tree

I can live with that, as long as the responsibility that packages work
with dependencies from overlays stays entirely with the overlay's
maintainer.

But could you please add a comment in the virtual's ebuild where (i.e.
in which overlay) the additional dependencies can be found?

Ulrich

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Eray Aslan]

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

On Sun, Apr 24, 2011 at 07:39:55AM +0200, Ulrich Mueller wrote:
> I can live with that, as long as the responsibility that packages work
> with dependencies from overlays stays entirely with the overlay's
> maintainer.

Good point.  Agreed.

> But could you please add a comment in the virtual's ebuild where (i.e.
i> in which overlay) the additional dependencies can be found?

Done.

-- 
Eray Aslan
Developer, Gentoo Linux       eras <at> gentoo.org

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[William Hubbs]

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

On Sun, Apr 24, 2011 at 09:42:25AM +0300, Eray Aslan wrote:
> On Sun, Apr 24, 2011 at 07:39:55AM +0200, Ulrich Mueller wrote:
> > I can live with that, as long as the responsibility that packages work
> > with dependencies from overlays stays entirely with the overlay's
> > maintainer.
> 
> Good point.  Agreed.
> 
> > But could you please add a comment in the virtual's ebuild where (i.e.
> i> in which overlay) the additional dependencies can be found?
> 
> Done.

Better yet,

why don't welook into moving those packages from the overlays into the
main tree?

William


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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[William Hubbs]

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

On Sat, Apr 23, 2011 at 09:05:48AM +0300, Eray Aslan wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
> 
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
> 
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right.  Additionally, keeping track of all the overlays and their
> package versions, USE flags and flag changes are potentially too much to
> track.  We will be making changes to a virtual package without testing
> whether it works.
> 
> On the other hand, we are making life (unneccesarily?) difficult for
> overlay users by not incorporating the requested changes to the official
> tree.
> 
> Comments on how to proceed?  Is it OK for a virtual to list a package
> which is in an overlay in RDEPEND?
 
 I would say no for the reasons you list above.

 I'm not an overlay user, but I'm thinking that an overlay user might be
 able to get around this by putting the virtual in package.provided.

William

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:

>  I'm not an overlay user, but I'm thinking that an overlay user might be
>  able to get around this by putting the virtual in package.provided.
>   

Why must the user do it? Can't the package manager do it?


Regards,
Chi-Thanh Christopher Nguyen

[gentoo-dev] Re: RDEPENDing on packages from overlays?

[Diego Elio Pettenò]

Il giorno sab, 23/04/2011 alle 09.05 +0300, Eray Aslan ha scritto:
> 
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right.  Additionally, keeping track of all the overlays and their
> package versions, USE flags and flag changes are potentially too much
> to
> track.  We will be making changes to a virtual package without testing
> whether it works.

Okay this is tricky.

From one side, we've done this before. Do note: we are _not_ going to
accept forced or non-use-masked dependencies for packages that are not
in tree, but || () dependencies on non-existing packages have been used
before, for instance while Gentoo/FreeBSD was still in its original
development.

On the other hand handling the current new-style virtual mess is enough
of a task without having to bend over backward to overlays.

As long as _somebody_ feels like doing the work, I suppose it's fine.

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Ciaran McCreesh]

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

On Sat, 23 Apr 2011 09:05:48 +0300
Eray Aslan <eras@gentoo.org> wrote:
> Comments on how to proceed?  Is it OK for a virtual to list a package
> which is in an overlay in RDEPEND?

The way || ( ) dependencies are defined means doing so doesn't cause
any problems.

Having said that, overlays can always supply their own version of the
virtual package if they prefer. It's not ideal, but it does mean that
overlays aren't subjected to the whim of whoever's handling the virtual
in the main tree.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RDEPENDing on packages from overlays?

[Thomas Sachau]

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

Am 23.04.2011 08:05, schrieb Eray Aslan:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
> 
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
> 
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right.  Additionally, keeping track of all the overlays and their
> package versions, USE flags and flag changes are potentially too much to
> track.  We will be making changes to a virtual package without testing
> whether it works.

"Doesnt seem right" sounds like a feeling, but is no real argument for me.

Afaik you dont need to track package versions, USE flags or flag changes at all for those requested
additions, so i dont see any potential additional work in the first place. If an overlay package
changes and requires an adjustment in the virtual, the overlay maintainer has to track it and has to
request the changes, not much to do on the virtual maintainer side. And since there always is at
least one choice in the main tree, it would not even harm other people, if the overlay package is
broken at any time.

> 
> On the other hand, we are making life (unneccesarily?) difficult for
> overlay users by not incorporating the requested changes to the official
> tree.
> 
> Comments on how to proceed?  Is it OK for a virtual to list a package
> which is in an overlay in RDEPEND?
> 


-- 
Thomas Sachau

Gentoo Linux Developer


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