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