Nice finding.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1061#issuecomment-585614753___
Rpm-maint mailing list
> Note that the subpackages approach has a problem if an extra goes away and it
> was installed on user machine.
Maybe not a *huge* concern... setuptools' documentation tells developers not to
do that.
Oh. There would be no way to buildrequire an extra. Is that what you mean?
That's a problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We know the runtime requirements during the build. What do you mena by this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can't properly do it right now. It would need to be expanded on buildtime,
but buildtime requirements != runtime requirements.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
So either we have a solution trough subpackages that is somewhat nice, but it
requires a feature that is missing in RPM and a feature that is missing in DNF,
or we do it trough reverse deps and that can be done right now, but is somewhat
ugly?
--
You are receiving this because you are
They would depend on main package tied to NVR, and have broken deps after
upgrade. And that should be just auto-removed by DNF (no such feature exists,
but it is not very hard to implement in dnf.conf `autoallowremove=*+*`).
--
You are receiving this because you are subscribed to this thread.
I still have no idea about what we would do with the obsoleted subpackages.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@hroncok of course that would be nice. And something what we have discussed
with @ffesti. He even asked me to send sumup how we would use that in Rust:
http://lists.rpm.org/pipermail/rpm-ecosystem/2020-February/000730.html
While there is no commitment or anything like that from anybody, I think
So only trough an external tool. What we are looking at are possibilities to do
this in fully automated fashion from the requirements generators.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Can you do that automatically?
Yes, it is done in rust2rpm. It generates spec file with bunch of subpackages
for each feature. And dependency generators support them, based on the name of
subpackage, it extracts feature and adjust generation of Provides/Requires.
--
You are receiving this
Can you do that automatically?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1061#issuecomment-584137625___
Rpm-maint
@hroncok generate bunch of subpackages for the optional features (extras) and
support them.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> we already do this for rust packages
You do what exactly?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> This needs to be in python-rpm-generators, that's why I discuss this here. It
> can be done "immediately". @ignatenkobrain when can we expect dynamic
> subpackages?
Hopefully as soon as @ffesti has time :)
---
@hroncok, the whole reason to not reimplement the wheel is that we already do
@pmatilai Thanks for confirmation :unicorn:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1061#issuecomment-584109272___
@hroncok , dynamic sub-packages is nothing but a pink pony in our daydreams
ATM, don't hold your breath waiting for that to happen.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Note that the subpackages approach has a problem if an extra goes away and it
was installed on user machine.
Obviously, if we loose extras that are still dependent on, any approach will
generate broken dependencies; but with subpckages, any removed subpackages will
need to be obsoleted, and
> if later, or just a little sooner: Don't bother.
> if a bit sooner: Put it in pyproject macros as an implementation detail, but
> document that it shouldn't be done manually. As much as possible, ensure it
> can be easily switched to dynamic subpackages.
> if much sooner (years): Go for it all
I won't be able to think through all the edge cases soon to give you "this
doesn't work, because..." kind of feedback. But "reverse requirements" do look
viable.
I guess my question is: when can this be done, relative to proper support for
dynamic subpackages?
* if later, or just a little
> > attach dependencies to virtual provides
>
> I'm sorry, what do you mean by this?
That wasn't well-specified, sorry ... I basically meant providing something
that can require something - like a proper virtual package specifed by Provides
that can also specify Requires. So, like a "virtual
Dynamic subpackages is something what's already planned for the future.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> attach dependencies to virtual provides
I'm sorry, what do you mean by this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Well, it's better than nothing.
I don't think you can attach dependencies to virtual provides? Doing that would
solve this issue ...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The idea is that we handle buildrequires and requires fully automatically,
generating subpackages statically is a step back.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think the subpackages approach is simpler, and has a lower cognitive burden
on the user than the "reverse provides requires rich dependencies" (that's a
mouthful ...). I am also reluctant to introduce another source of "if" rich
dependencies, which still aren't really correctly handled by
In Python, we have a concept of
[extras](https://packaging.python.org/specifications/core-metadata/#provides-extra-multiple-use)
a way to specify an optional dependency with the ability to install the
software with that dependency enabled trough the "extra" part of a name in
square brackets.
27 matches
Mail list logo
