repository, you could directly ask me
Does anyone have suggestions on that topic?
Again, many thanks.
I really hope that with everyone's feedback, suggestions, and help, we could
make something useful from this prototype.
Michael Lienhardt
PS: I forgot in my previous mail to talk about the other
or missed.
Best Regards,
Michael Lienhardt
PS: list of uninstallable packages:
dev-java/jruby-1.7.12
media-video/nvidia-settings-340.58
dev-ruby/bitescript-0.0.9
dev-java/spring-core-3.2.4
app-i18n/ibus-table-code-1.2.0.20100305
dev-ruby/weakling-0.0.4
sci-libs/ogdi-3.1.5-r1
dev-java/jcs-2.0
Dear Alexander,
Many thanks for the advices.
I started few discussions on the forum and will go to FOSDEM.
I'll see where it will go.
Best,
Michael
Il 16/12/2017 14:39, Alexander Berntsen ha scritto:
On 13/12/17 02:52, michael.lienha...@laposte.net wrote:
But maybe there are things we can do
Is the IUSE_IMPLICIT variable in the make.defaults also changed into
IUSE_EFFECTIVE?
I'm sorry if this question was already discussed/answered somewhere else.
Michael
Il 04/02/2018 14:40, Michał Górny ha scritto:
Rename the iuse_implicit variable used in USE_EXPAND handling to
Many thanks.
I should definitively read this document, that is far more precise that
anything I have found on the wiki or on devmanual.
Il 06/02/2018 00:05, Zac Medico ha scritto:
On 02/05/2018 02:46 PM, Michael Lienhardt wrote:
Is the IUSE_IMPLICIT variable in the make.defaults also changed
Dear all,
A few months ago, I got back to my constraint-based dependency solver for
portage, that I had to leave for a while.
Thanks to Zac Medico, it is now based on portage itself to query the portage
tree, and so the code is far simpler (and far less buggy).
It is on github:
- Zac Medico a écrit :
> It's capable of considering older versions, but maybe there's some
> deficiency in the algorithm. We should analyze a specific example in
> order to understand the behavior.
>
> Maybe you're referring to this code which forces the highest version in
> the event of
Dear all,
It's possible that the goal of my current work and its possible benefit for the
gentoo community are not very clear.
In my experience, emerge is a very good tool to install new packages whose use
flags have already been configured.
However, when the packages are not correctly
- Alec Warner a écrit :
> On Tue, Mar 24, 2020 at 11:31 AM wrote:
> > However, I still doubt that only storing the soname dependencies is enough.
> > Consider package A (that cannot be recompiled) that depends on package B
> > which provides lib L.so.
> > B is recompiled with different use
- Alec Warner a écrit :
> Sorry I'm being overly academic. My concern earlier is that you mentioned a
> goal of "never breaking installed packages' which I found to be a fairly
> audacious goal. The idea is that we should build tools that achieve this
> practically (e.g. via heuristics
Dear all,
Still in the process of improving my solver (and make it a usable tool), I need
to have a better idea on how installed packages should be managed.
I didn't find anything on that topic in the PMS (if I've missed it, I'm sorry).
Could you confirm/correct my following understanding:
1.
- Zac Medico a écrit :
> > 3. before removing a library, "ebuild unmerge" always checks if it is used
> > by another package: this means that installed packages' dependencies are
> > never broken.
>
> That's true if the package is removed via emerge --depclean, but emerge
> --unmerge
- Zac Medico a écrit :
> > The goal of my tool is to have correct manipulation of package
> > dependencies, and in particular here, I focus on the packages that are
> > installed but not in the portage tree/a local overlay anymore (the problem
> > does not occur for other packages).
> >
On 6/17/20 1:25 AM, Zac Medico wrote:
> On 6/16/20 7:47 PM, Michael Lienhardt wrote:
>>
>>
>> On 6/16/20 11:59 PM, Zac Medico wrote:
>>> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>>>> With the first version of DEPEND, emerge succee
Le 17/06/2020 à 08:15, Michał Górny a écrit :
On Tue, 2020-06-16 at 23:07 +, Michael Lienhardt wrote:
Dear all,
My bad for not noticing it sooner, but when there is a dependency like
">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in
virtual/libgudev-215-r3),
Le 17/06/2020 à 10:35, Ulrich Mueller a écrit :
On Wed, 17 Jun 2020, Michael Lienhardt wrote:
But maybe, "error" here in the PMS mean "the cpvs without the use flag
does not match that dependency and a warning should be raised to
improve compatibility in the future". In
I'm sorry, my client didn't allow to send plain text email anymore...
So, here is my original email.
Dear all,
My bad for not noticing it sooner, but when there is a dependency like
">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in
virtual/libgudev-215-r3),
since 'static-libs' is not
On 6/16/20 11:59 PM, Zac Medico wrote:
> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>> With the first version of DEPEND, emerge succeed:
>> # emerge -pv app-misc/dummy-master
>>
>> These are the packages that would be merged, in order:
>>
>> Calculat
On 6/16/20 9:31 PM, Zac Medico wrote:
> On 6/16/20 11:07 PM, Michael Lienhardt wrote:
>> I'm sorry, my client didn't allow to send plain text email anymore...
>>
>> So, here is my original email.
>>
>> Dear all,
>>
>> My bad for not noticing i
19 matches
Mail list logo
