From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Repository stacking and complementary overlays
Date: Thu, 05 Mar 2009 01:16:53 -0100 [thread overview]
Message-ID: <49AF3615.2020503@gentoo.org> (raw)
In-Reply-To: <49AF31C3.6090000@gentoo.org>
-----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-----
next prev parent reply other threads:[~2009-03-05 2:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-27 2:41 [gentoo-dev] Repository stacking and complementary overlays Mart Raudsepp
2009-03-02 16:48 ` Ciaran McCreesh
2009-03-02 23:55 ` Gilles Dartiguelongue
2009-03-02 23:59 ` Ciaran McCreesh
2009-03-04 9:17 ` Gilles Dartiguelongue
2009-03-05 1:37 ` Jorge Manuel B. S. Vicetto
2009-03-05 1:58 ` Zac Medico
2009-03-05 2:16 ` Jorge Manuel B. S. Vicetto [this message]
2009-03-05 10:20 ` Marijn Schouten (hkBst)
2009-03-05 12:24 ` Marijn Schouten (hkBst)
2009-03-05 13:47 ` Daniel Pielmeier
2009-03-18 2:30 ` Mart Raudsepp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49AF3615.2020503@gentoo.org \
--to=jmbsvicetto@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox