| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Zac Medico wrote: |
| 5 |
> Jorge Manuel B. S. Vicetto wrote: |
| 6 |
>> This seems desirable and reasonable. |
| 7 |
>> As I replied to this subject earlier regarding KDE, let me complement |
| 8 |
>> that information. In the case of the KDE team, we keep work on a release |
| 9 |
>> all in the same place, so we don't need to unmask some KDE packages in |
| 10 |
>> tree for those using the overlay. However, we some times have deps on |
| 11 |
>> packages from other teams and or in other overlays, so I hope the repo |
| 12 |
>> deps would help here (not to unmask those packages, if they're masked, |
| 13 |
>> but to add a dep on a particular repo and allowing the PM explain to the |
| 14 |
>> user that he/she needs to unmask a particular version in the tree / |
| 15 |
>> overlay). |
| 16 |
> |
| 17 |
> The problem with repo deps is that they're too restrictive since |
| 18 |
> they assume that only a specific repo can satisfy the dep. Suppose |
| 19 |
> that you migrate some of the packages from the overlay to the main |
| 20 |
> tree? Now you've got installed packages that are trying to pull in |
| 21 |
> deps from the wrong repo. Or suppose that somebody else has an |
| 22 |
> overlay with a compatible package? |
| 23 |
|
| 24 |
I agree repo deps might be restrictive, but in some cases we might |
| 25 |
really want to be restrictive. For instance, I might want to have a dep |
| 26 |
on a package in the GNOME official overlay - I might not want to get the |
| 27 |
version in some other overlay listed in layman. |
| 28 |
When the package moves to the tree or if work moves to another overlay, |
| 29 |
then sure, it will mean more work. But sometimes that might be preferred. |
| 30 |
|
| 31 |
> I think a better way to reference another repo is with the |
| 32 |
> layout.conf approach suggested in the "QA Overlay Layout support" |
| 33 |
> thread [1]. For example, if packages from the java-experimental repo |
| 34 |
> depend on some ebuilds or eclasses from the java-overlay repo, it's |
| 35 |
> specified via a "masters" entry in layout.conf. If any of those |
| 36 |
> ebuilds/eclasses happen to migrate to the main tree then the |
| 37 |
> migration is seamless. |
| 38 |
|
| 39 |
I like this proposal as well. I think repo deps and "master layouts" are |
| 40 |
complementary and not alternatives. Getting back to KDE (sorry for being |
| 41 |
so self-centered), we would make the kde-experimental overlay have |
| 42 |
kde-testing as the master overlay. So we could do some work in eclasses |
| 43 |
in kde-testing without needing to copy them to kde-experimental. |
| 44 |
|
| 45 |
> [1] |
| 46 |
> http://archives.gentoo.org/gentoo-dev/msg_33c61550b4ed2b7b25dd5a4110e1ec81.xml |
| 47 |
|
| 48 |
- -- |
| 49 |
Regards, |
| 50 |
|
| 51 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
| 52 |
Gentoo- forums / Userrel / Devrel / SPARC / KDE |
| 53 |
-----BEGIN PGP SIGNATURE----- |
| 54 |
Version: GnuPG v2.0.10 (GNU/Linux) |
| 55 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 56 |
|
| 57 |
iEYEARECAAYFAkmvNhUACgkQcAWygvVEyAJTDwCfeFwqVMtUY4r+BR5mX6kyGhuk |
| 58 |
tTAAoJG0kQksJnVM6Fd/WwPHxJmBJZoi |
| 59 |
=eSaw |
| 60 |
-----END PGP SIGNATURE----- |
Archives