Gentoo Archives: gentoo-qa

From: Zac Medico <zmedico@g.o>
To: gentoo-qa@l.g.o
Subject: Re: [gentoo-qa] Support of other package managers
Date: Wed, 17 May 2006 02:55:02
Message-Id: 446A907D.8040504@gentoo.org
In Reply to: Re: [gentoo-qa] Support of other package managers by Mark Loeser
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Mark Loeser wrote:
5 > This is the exact problem I'm trying to address. You'll never get all
6 > of the projects to agree, since they all want to go in slightly
7 > different directions and do different things. All three are great
8 > ideas, but we should only support the one that is official for Gentoo,
9 > and not make any changes to the tree. (Note: changes here is any
10 > modification or addition of files in the tree for the sole purpose of
11 > working with an alternate package manager)
12
13 I don't see any reason to include support for a non-official package manager in the official gentoo repo either (given that they can host their own repository and include whatever they want). For the sake of interoperability, I hope that the developers of these separate package managers can come together and agree on some specifications, but that's a topic for another list...
14
15 > Either way, I think this is something we should hold off on for now, and
16 > have the council decide upon. We shouldn't just make these changes
17 > without having some discussion taking place (the flamewar on g-dev@ is
18 > not a discussion, and is only a small minority of people giving their
19 > two cents).
20 >
21 > Whatever the decision is, the addition of another package manager makes
22 > QA harder to do since we have to consider all of them. Adding a new
23 > package manager and saying we don't support it, nor are we sure if we
24 > will ever support it, does not seem acceptable at all to me. The
25 > decision should be made if we plan on supporting it so we can work on
26 > actually supporting it, or if this should be a completely separate
27 > project and they can work on their own to make changes to ebuilds which
28 > support their own functionality.
29
30 Yeah, it seems like this type of decision needs to be made by the council, and I hope that they decide against it.
31
32 Zac
33 -----BEGIN PGP SIGNATURE-----
34 Version: GnuPG v1.4.3 (GNU/Linux)
35
36 iD8DBQFEapB8/ejvha5XGaMRAvJOAJ9D9bkg7UoMynFNND+S8UJfLurDlwCeLeJH
37 EzwX3OXW21TjqytMynWfwUE=
38 =aGr0
39 -----END PGP SIGNATURE-----
40 --
41 gentoo-qa@g.o mailing list