08.12.2013 20:54, Tom Wijsman пишет:
> Hello fellow developers
>
> == Situation ==
>
> When specifying a dependency like cat/pkg it will default to cat/pkg:*
> which is defined in `man 5 ebuild` as:
>
> * Indicates that any slot value is acceptable. In addition,
> for runtime depend
[reordered to ease replying]
Rich Freeman writes:
> Now, perhaps a more balanced approach might be to mask it and give 15
> days notice on -dev, and then it can be unmasked. Anybody who cares
> about the library can test the new version, and if necessary update
> their dependencies to use the pr
On Sun, Dec 8, 2013 at 9:37 PM, wrote:
>
> How about defining a QA workflow for introducing a new slot of a
> library, such as "mask it and open a tracker bug until every individual
> reverse dependencies are checked"?
>
The problem with this is that it puts the onus on the person who wants
to m
Rich Freeman writes:
> A new slot of a package (which doesn't exist today) may or may not
> work with any ebuild in the system. Should it be considered a best
> practice then to specify || deps with all slots that are known to work
> in the tree? Or should we just trust to luck and consider it
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2013-12-08 23h59 UTC.
Removals:
app-arch/xarchiver 2013-12-02 19:53:10 hwoarang
kde-misc/kio-upnp-ms2013-12-04 21:05:27 johu
kde-misc/qtrans 20
On Sun, Dec 8, 2013 at 6:57 PM, Patrick Lauer wrote:
> On 12/09/2013 12:54 AM, Tom Wijsman wrote:
>>
>> One thing that directly comes to mind is that dependencies that have no
>> SLOT="0" ebuild present would need us to manually specify a specific
>> SLOT; given that this is a not so common situat
On Mon, 09 Dec 2013 07:57:34 +0800
Patrick Lauer wrote:
> On 12/09/2013 12:54 AM, Tom Wijsman wrote:
>
> > Creating a new SLOT is the most sane thing going forward; but, as
> > the default (:*) depends on any SLOT, this needs a half thousand
> > commits to fix up reverse dependencies. Thus, inst
On 12/09/2013 12:54 AM, Tom Wijsman wrote:
> Creating a new SLOT is the most sane thing going forward; but, as the
> default (:*) depends on any SLOT, this needs a half thousand commits to
> fix up reverse dependencies. Thus, instead a new package is made. [1]
Pff. Lazy.
> When our defaults f
On Sun, Dec 08, 2013 at 03:34:59AM +0100, Peter Stuge wrote:
> Rich Freeman wrote:
> > I can see the argument in making the installation of a network manager
> > part of the handbook. We already have a whole page on how to set up
> > the network for the install CD itself assuming dhcp doesn't just
On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote:
> 1.) If we are going to stuff this into @system then we probably want a
> USE=nonet flag to allow users to not pull anything in if they really
> don't want it.
We don't have to put this in @system at all. We could just have
On Sun, 8 Dec 2013 22:54:39 +0100
Michał Górny wrote:
> > Actually, Paludis interprets a lack of slot dependency as a "don't
> > know", and assumes that it might be unsafe to switch slots at
> > runtime in these cases.
>
> So we should basically encourage people to explicitly state ':*' when
> th
Dnia 2013-12-08, o godz. 20:26:44
Ciaran McCreesh napisał(a):
> On Sun, 8 Dec 2013 21:21:52 +0100
> Ulrich Mueller wrote:
> > > The PMS describes package manager behavior required to support an
> > > ebuild repository. If I read the PMS correctly, SLOT-less
> > > dependencies have undefined beha
On Sun, 8 Dec 2013 21:21:52 +0100
Ulrich Mueller wrote:
> And all package managers interpret it in the same way.
If all package managers do as such, that allows PMS to easily cover it.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public
> On Sun, 8 Dec 2013, Ciaran McCreesh wrote:
>> Nothing undefined here. A dependency without a slot means that all
>> slot values are acceptable. And all package managers interpret it in
>> the same way.
> Actually, Paludis interprets a lack of slot dependency as a "don't
> know", and assumes
On Sun, 8 Dec 2013 21:21:52 +0100
Ulrich Mueller wrote:
> Nothing undefined here. A dependency without a slot means that all
> slot values are acceptable.
Is that stated in the PMS?
> And all package managers interpret it in the same way.
Because it is the previous behavior (adopted from versi
On Sun, 8 Dec 2013 21:21:52 +0100
Ulrich Mueller wrote:
> > The PMS describes package manager behavior required to support an
> > ebuild repository. If I read the PMS correctly, SLOT-less
> > dependencies have undefined behavior; this makes it so that if you
> > have a different package manager us
On Sun, 8 Dec 2013 21:21:59 +0100
Tom Wijsman wrote:
> On Sun, 8 Dec 2013 21:01:00 +0100
> Ulrich Mueller wrote:
> > > On Sun, 8 Dec 2013, Rich Freeman wrote:
> >
> > > Sure it does - it defaults to :* when :* was never specified. I
> > > don't see how defaulting to :0= is a "policy" any mor
On Sun, 8 Dec 2013 21:01:00 +0100
Ulrich Mueller wrote:
> > On Sun, 8 Dec 2013, Rich Freeman wrote:
>
> > Sure it does - it defaults to :* when :* was never specified. I
> > don't see how defaulting to :0= is a "policy" any more than :* is.
>
> Defaulting to :* is just the long term behavio
> On Sun, 8 Dec 2013, Tom Wijsman wrote:
> The PMS describes package manager behavior required to support an
> ebuild repository. If I read the PMS correctly, SLOT-less dependencies
> have undefined behavior; this makes it so that if you have a different
> package manager using the same ebuild
On Sun, Dec 8, 2013 at 3:01 PM, Ulrich Mueller wrote:
> Our rules of slot/subslot dependencies and slot operators are just
> complicated enough, so I really would dislike complicating them even
> more by having an EAPI dependent default. In addition, from a package
> manager view there is nothing
On Sun, 8 Dec 2013 20:14:47 +0100
Ulrich Mueller wrote:
> > On Sun, 8 Dec 2013, Andreas K Huettel wrote:
>
> > How about changing this in the next EAPI instead?
>
> > E.g., in EAPI=6, if no slot dependency is given in a dependency
> > specification, default to :0
>
> PMS just provides a me
> On Sun, 8 Dec 2013, Rich Freeman wrote:
> Sure it does - it defaults to :* when :* was never specified. I don't
> see how defaulting to :0= is a "policy" any more than :* is.
Defaulting to :* is just the long term behaviour from EAPIs 0 to 4
when no slot operator was specified. This is cons
On Sun, 8 Dec 2013 14:39:39 -0500
Rich Freeman wrote:
> On Sun, Dec 8, 2013 at 2:14 PM, Ulrich Mueller wrote:
> > PMS just provides a mechanism, but doesn't prefer one SLOT value
> > over another. Such a change would introduce policy into PMS which
> > is not the right way to go.
>
> Sure it doe
On Sun, Dec 8, 2013 at 2:14 PM, Ulrich Mueller wrote:
>
> PMS just provides a mechanism, but doesn't prefer one SLOT value over
> another. Such a change would introduce policy into PMS which is not
> the right way to go.
Sure it does - it defaults to :* when :* was never specified. I don't
see ho
> On Sun, 8 Dec 2013, Andreas K Huettel wrote:
> How about changing this in the next EAPI instead?
> E.g., in EAPI=6, if no slot dependency is given in a dependency
> specification, default to :0
PMS just provides a mechanism, but doesn't prefer one SLOT value over
another. Such a change wou
On Sun, Dec 8, 2013 at 12:46 PM, Tom Wijsman wrote:
>
> Given that the retroactive change I suggest causes a lot of complexity;
> changing it on the next EAPI indeed sounds like one way to go, the
> alternative is to make it a suggestive guideline or policy and cover
> it as a QA check in repoman.
On Sun, 08 Dec 2013 18:26:25 +0100
Pacho Ramos wrote:
> El dom, 08-12-2013 a las 18:19 +0100, Andreas K. Huettel escribió:
> > Am Sonntag, 8. Dezember 2013, 17:56:12 schrieb Tom Wijsman:
> >
> > > When our defaults force us down such path, that can't be good and
> > > it affects the quality of ou
El dom, 08-12-2013 a las 18:19 +0100, Andreas K. Huettel escribió:
> Am Sonntag, 8. Dezember 2013, 17:56:12 schrieb Tom Wijsman:
> >
> > When our defaults force us down such path, that can't be good and it
> > affects the quality of our Portage tree; so, this makes me wonder, can
> > we change the
Am Sonntag, 8. Dezember 2013, 17:56:12 schrieb Tom Wijsman:
>
> When our defaults force us down such path, that can't be good and it
> affects the quality of our Portage tree; so, this makes me wonder, can
> we change the default from :* to :0? What do you think?
>
I see the point, but I have my
Dnia 2013-12-08, o godz. 17:56:12
Tom Wijsman napisał(a):
> Hello fellow developers
>
> == Situation ==
>
> When specifying a dependency like cat/pkg it will default to cat/pkg:*
> which is defined in `man 5 ebuild` as:
>
> * Indicates that any slot value is acceptable. In addition,
>
Hello fellow developers
== Situation ==
When specifying a dependency like cat/pkg it will default to cat/pkg:*
which is defined in `man 5 ebuild` as:
* Indicates that any slot value is acceptable. In addition,
for runtime dependencies, indicates that the package will not
break
Hello fellow developers
== Situation ==
When specifying a dependency like cat/pkg it will default to cat/pkg:*
which is defined in `man 5 ebuild` as:
* Indicates that any slot value is acceptable. In addition,
for runtime dependencies, indicates that the package will not
break
32 matches
Mail list logo
