On 08/26/2014 08:15 PM, Peter Robinson wrote:
What's the rationale here? I mean, we have so many dependencies, if
you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with
these dependencies. A lot. Finding a minimal set of RPMs to
Well, Fedora is not a distribution that cares about whether it is easily
bootstrappable. It never was a goal to be one. If you want to make it
one, then that's fine, but that'd be something to make an official goal
first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or
that Debian tries to be then that's OK. I personally don't think it is
worth the effort though, as we don't have to bootstrap new archs every
other week...
I believe that's something that the Base working group is actually
actively trying to achieve, Phil or one of the members might be able
to comment further on their exact plans for this.
Right. So the main focus right now is first of all cleaning up what
buildrequires we have and targeting the things that would will make a
big difference.
For one thats the work Benedikt Morbach has been working on over the
past 2 months in regards to automatically finding potentially
unnecessary buildrequires and then working with upstream and Fedora
maintainers on fixing them.
The next topic we've started looking at is more related to the
bootstrapping. Granted, we don't do that every release, but as the past
several years has show us new architectures can pop up rather quickly,
and bootstrapping Fedora right now is a real pain as me, Peter and
Dennis can attest to.
But there the issue is more cyclic dependencies, especially among core
components. As long as we get those fixed the rest will be "relatively"
easy. It's still much more than a simple rpmbuild --rebuild foo.srpm,
but a goal would be to get to that state without having to jump through
3 very heavily scripted and hacked manual stages with lots of ugly stuff
in the builds happening there.
I agree though that this is relatively unimportant for everyday
operation in Fedora (or any distribution for that matter) and a typical
developer/maintainer probably doesn't care (and probably shouldn't, really).
Now, coming to systemd and the requirements there, i'm all for removing
unnecessary requirements, and especially with our increasing focus on
containerized applications and images (e.g. docker or similar) i'd love
to see very lean images by default being constructed with default
packages without any post install hacks again, so i'd personally
appreciate it if that would be fixed, but it's certainly not the end of
the world if it isn't and by far less severe than other disasters that
happened in packaging in Fedora (see texlive, but we're trying to fix
some of that insanity).
I'm less inclined to agree with the argument for mock and builds now
taking much longer to run due to these requirements. Looking at some of
the examples (and having run a few of my own), the typical additional
number of packages with or without the subpackage is usually very low
(aka, below 10) and won't affect build time drastically.
cross-compile to get a bootable core was very difficult because of
dependencies, and managing the path up to koji was a nightmare. Even
after that, there were some packages that couldn't be built *at all*
because of circuilar dependencies or dependencies on them.
Cyclic dependencies are something that so far was accepted in
Fedora. If you want to get rid of that, then make it a Fedora goal...
For many packages getting rid of the cyclic deps would mean having to
build things twice, but I am not sure this is really worth the work...
Well if you can set a boostrap flag in the distro, run a set of
builds, unset the flag, bump and rebuild it's really not that much
work,
Aye, but thats still work that we have to flash out in more detail and
then get someone actively really working on it. The basic principle is
"easy" (see the bootstrap flag in the perl-* packages), but making sure
it is being properly done and maintained is a different matter.
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a
while, but you demonstrate the worst traits of engineering. If
there's a problem, you don't hide it or just "let it be because we're
used to it." You *fix* it. And you make sure it *stays* fixed. Take
some pride in your work! Do the best you can! If you're only willing
to do mediocre work and let problems exist because you can't be
bothered to fix them, then Fedora will at best be a mediocre product.
You know, some cyclic des might be easy to resolve, but a big chunk
really isn't. And our core OS stuff is full of it. I think you
underestiate the complexity of this.
There's actually been some analysis done of this and people are
actively working to reduce them.
Peter
Exactly, as i've said, doing that manually is rather insane (see
http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/ for some
funny graphics regarding this), and the dependency creep that happened
in Fedora over the past 10+ years is really the cause of it.
So addressing this and focusing then on the 80% of the real issues
instead of picking and tiny bits left and right will yield a much bigger
bang for the buck, therefore as long as systemd itself doesn't start to
do cyclic dependencies i'm personally fine with it being pulled in
occasionally.
Thanks & regards, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Manager Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch@xxxxxxxxxx>
Wankelstrasse 5 | Web: http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
