Re: Modularity vs. libgit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Adam and everyone else,

I want to point out that there are 2 issues and not just one as
described in the article.

1) Default streams can't conflict
2) Switching dependencies on a module does not work

Both of the issues are solvable and should be handled by DNF, however
they are not. And I could not get any ETA on fixing that.

So the article talks about second issue. I'll comment on it first and
then I'll talk more about first issue.

# One stream with compatibility packages

This is not entirely doable. While library itself can be installed in
parallel, the devel package can not. So this would mean I would either
have to ship only one devel package which would not make sense or do
terrible hacks to install them in parallel (like mangling /usr/include
directory, pkg-config and such) and it won't work correctly. And after
all, what is the advantage of modularity in this case? I can do the
same in traditional Fedora.

# New streams of silver and bat

So we will have then silver:rolling, silver:rolling-new,
silver:rolling-very-new and such? Note that I simply can't support old
streams. They would need to go EOL as soon as I create new one. And we
decided not to do. Streams must be supported by people within active
Fedora release. So this is not solution to a problem at all.

# Bundle libgit into the silver and bat modules

Yes, I can link libgit2 statically everywhere. I don't even have to
include that package, I just have to ship static version of libgit2.
The problem here is that since in Fedora we don't have any automation
for rebuilding modules / packages, every time something changes in
libgit2, I would have manually go, check what to rebuild and do that
rebuilds.

# Potential solutions for the future

So we don't even look at solution named "Just Fix DNF"?


Now to the problem which was not described in the article.. In order
to describe, I'll start in short points what was before and what has
changed.

* Fedora 29 and 30 have non-modular libgit2-0.27
* Fedora 31 has had non-modular libgit2-0.27 as well, but last or this
week has upgraded to libgit2-0.28
* All Fedora versions ship 0.26, 0.27 and 0.28 streams of libgit2 as a modules
* All Fedora versions have default stream set to match non-modular
version (due to not having Ursa Prime ready)
* silver, bat, exa and more modules have default stream and used to
depend on libgit2:0.27 and have been rebuilt (most of them) to depend
on libgit2:0.28

Here I should introduce what "default stream" means for users. Users
should be able to just do "dnf install silver" and that should enable
default stream of module which provides package "silver". That means,
until you do installation, they can conflict. It might be not very
nice for users, but this is valid. So if we have default tokei:rolling
which depends on libgit2:0.27 and default libgit2:0.28, you should be
able to install either tokei which would install libgit2:0.27 or if
you do "dnf install libgit2", it would install 0.28 and you won't be
able to install tokei. What happens today is DNF just always complains
and does not allow you to install an operating system.

So simply untagging new builds of modules won't help, because then
modules will start depending back on libgit2:0.27 while rawhide has
already default for libgit2:0.28. Neither you can change a default
back to 0.27 because non-modular libgit2 has been upgraded and all
packages were rebuilt.

There are 2 solutions for this problem (not including fix of DNF):

1) Unset all defaults for Rust applications. This will solve problem
of not being to install an OS, but it won't solve issue with upgrades.
2) Untag new builds for Fedora 29 and 30, stop shipping updates for
Rust applications there and let them rot. For rawhide, I can rebuild
last few modules to start depending on libgit2:0.28, so rawhide will
be back on track.

First option is just horrible. Second one is okay-ish, but before this
way would be chosen I want to hear what is the ETA for fixing these
DNF bugs. I do not want Rust applications just rot in stable releases.

On Thu, Jun 13, 2019 at 9:22 PM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
>
> So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a help of a few people, I've put together this post to get us on common ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
>
> There are few ideas about solving the issue right now. But we might be able to think about better ways to deal with similar issues long-term. Let's do this!
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1717117
> [2] https://pagure.io/fesco/issue/2146#comment-575852
> --
>
> Adam Šamalík
> ---------------------------
> Senior Software Engineer
> Red Hat
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux