Gentoo Archives: gentoo-dev

From: Franz Fellner <alpine.art.de@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Date: Fri, 23 Mar 2018 10:39:06
Message-Id: CADtyuE5mbagtdiyzk=g6JmSavzowuHP+Voj_OiLLgfq=NxtRaw@mail.gmail.com
In Reply to: Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny by Francesco Riosa
1 The dlang repository offers a gcc ebuild that adds the patchset to build
2 the gdc. It's behind a USE-Flag. Still it is exactly the same as
3 sys-devel/gcc::gentoo besides the additional feature.
4 But I don't think the dlang repo should mask gcc::gentoo.
5
6 2018-03-23 12:18 GMT+02:00 Francesco Riosa <vivo75@×××××.com>:
7
8 >
9 >
10 > Il 23/03/2018 10:48, Ulrich Mueller ha scritto:
11 > >>>>>> On Thu, 22 Mar 2018, Geaaru wrote:
12 > >> for both portage and your fork I think that could be interesting add
13 > >> an extension to PMS for define inside profiles or targets masking of
14 > >> packages of a particular repslository. Currently PMS doesn't permit
15 > >> this but have this feature could be help users to define our
16 > >> profiles under overlays.
17 > >> Something like this:
18 > >> sys-devel/gcc::gentoo
19 > > Conceptually that makes no sense. sys-devel/gcc is the name of an
20 > > upstream package, so what does it even mean to mask it in one
21 > > repository but not in another? If it's the same package, then it
22 > > should behave in the same way, regardless of the repository its ebuild
23 > > it hosted in (or the package being installed, in which case it is no
24 > > longer in an ebuild repository).
25 > >
26 > > If it is a different package however, then it should have a different
27 > > name.
28 > Sorry to say it bluntly but this make no sense at all, even changing a
29 > USE flag make the package behave wildly differently.
30 > Once we agree that an upstream (complex enough) package may have
31 > different incarnations two ebuilds from different maintainers may please
32 > differently the user.
33 > I'm not sure this choice belong to profiles but not because same
34 > upstream correspond to same files on filesystem.
35 >
36 > >
37 > > Ulrich
38 >
39 >
40 >