On Wed, 30 Nov 2022 at 07:54, Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Wed, Nov 30, 2022 at 11:54:10AM +0000, Peter Robinson wrote: > > Hi Fabio, > > > > Been meaning to reply to this, but it got lost in the mail pile. > > > > > > > But running `cargo fetch` with a clean cache pulls down *390* > crates. Of > > > > these, it looks like 199 (!) are already packaged as > rust-[crate]-devel, > > > > which is *amazing*. But... that still is hundreds that I'd have to > add. And > > > > mostly they are things I don't know _anything_ about. > > > > > > You must realize that this is an extreme case. For many Rust > > > applications that people want to package for Fedora, the number of > > > dependencies that are missing is rather small, *because* most popular > > > libraries are already packaged. > > > > In my experience, and I'm not packaging any form of gaming engine, > > it's not an extreme case, for a few small things and one slightly > > larger thing I *have* packaged I now maintain over 60 more packages. I > > have another one I want to package and AFAICT I get to package another > > 50-100 but frankly it's hard to tell, and this is something I have > > control over and have been actively trying to do upstream reduction of > > deps. > > The magnitude of the number of deps is the real killer for not > only Rust, but also Go, and arguably anything that isn't a C > based application. > > Packaging up all of a project's deps individually is viable when > there are a relatively small number of them, especially if most > of the deps are shared by other apps, and the libraries have good > API + ABI stability promises. This is common in the case of most > C applications/libraries, since shared libraries are relatively > speaking fairly broad in functional scope, and often long lived, > because that is the mindset of the C ecosystem in general. > > Modern languages & their ecosystems though have brought about > a world where the granularity of deps is waaaaay smaller, where > the focus is on being able to evolve rapidly, with less focus > on long term stable API/ABI, as apps are expected to just fix > against specific versions they've tested on. > > I wonder if we should look at the standard libraries in the late 1960/1970 languages as being the same as 'opinionated' Operating Systems. Most of them started out with a period where every mainframe might have a 'language' and a set of 'libraries' of routines but every site pretty much mangled them to fit their own 'local' needs. Software vendors which existed usually ended up having consultants go out to 'fix' their code to match whatever routines and tooling existed on each mainframe. This got to be unworkable and various 'libraries' were put forward which were to standardize things. However, going from the 'old war tales' my mentors and professors from that era, the same arguments that the current languages (Rust, etc) have against standards were existent. The issue was the scale of the problem was much more on the side of the hardware/OS vendors putting out a standard chosen library (and then fighting over getting those to match up for the software vendors who still needed to spend a lot of consulting time). Most of those arguments seem to have 'died' out as people got tired of fighting the differences versus the delight of new challenges that many programmers have when dealing with a 'new' language. [Same with C++ back in the late 1980's where every vendor had a slightly different set of libraries which for its proponents was the best thing over all the others.. and then by the late 1990's was 'Oh no, not this again'. Java went through this up until the late 00's. ] I don't think we are at the state where enough of the new people who are getting into Rust have gotten tired of fighting 'oh, I have to f'ing change my code again to make it work with these 4 things?' Basically when enough people HAVE to code in the language versus just 'WANT' to, but hate the grind.. ability to standardize is going to happen. > So functionality that lives in single library in C, often ends > up being spread across 20-200 modules in any of the modern > non-C languages. We've been experiancing this problem in Fedora > for a very long time and while we have spec auto-generators, > that still leaves masses of busy work, and also still leaves > the problem that what we ship doesn't match what upstream has > tested, so the result is often less reliable. > > IMHO the only thing that can make packaging such fine grained > modules sustainable long term, is if the process could be 100% > automated. I don't mean just having a tool to auto-generate > a spec file. It needs to be fully automated to the extent that > you just tell a robot "i need deps for this package" and it > does everything automatically, except for human approval of > the results of a code license audit. > > That of course would be a non-trivial service to build, and > it still begs the question of whether its really beneficial > in the long term. > > At the moment, I think that it is probably the best goal for both opinionated operating system reasons, but also long term needs for a lot of 'customers'. This code is entering into a lot of highly regulated markets where everything needs to be captured and kept for lifetimes of people versus hardware and definitely longer than most 'software' sites (sourceforge anyone?). Being able to accurately capture exactly what was used, how it was used, and being able to independently audit it 20 years down the road has been in many ways the hidden 'charm' (or solution to a nightmare for the developer dealing with an audit of RHL6.2 in 2022) of operating systems. It is one of the things I see problematic in various central archives for code which people seem to rely on for their deliverables. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
