On Thu, 27 Nov 2014 14:28:01 +0100 Matthias Urlichs <matthias@urlichs.de> wrote: > Hi, > > Martin Steigerwald: > > But I think for most of the people that dislike systemd this is the > > main concern: systemd is a lot of system building blocks in *one* > > repository and *one* debian package and while they may be > > separatable they are not separated. > > > > But well, its an upstream topic and I actually tried to bring this > > upstream, but didn´t seem to be able to bring my point across > > What exactly _is_ the point? It's one git repository instead of five, > but what (technical) problem would having five repos and five Debian > source packages, instead of one, actually solve? Actually, not particularly thinking of systemd at this point, but in *general* there is a good technical advantage to this approach: migrations & dependency control. It avoids the "fingers in every pie" problem common to a number of source packages in Debian. It particularly applies to source packages with a lot of plugins or where particular sub-components bring in a unique list of build-dependencies or add unique install time dependencies. By having separate source packages, a stable API becomes mandatory. A stable API then means that libpluginA can migrate into testing independently of libbasefoo and libpluginB. Net result: libbase is no longer trapped in endless migration transitions when it is only one plugin/sub-component which is actually affected. Why, if I want to just patch libpluginF, must I download the entire source package of libbasefoo, libpluginA ... libpluginJ and all those build-dependencies and then waste time building all the stuff I don't need and testing it all... Make a stable API and release libpluginA as a separate source package from libpluginF etc. Persuading upstream to create a stable API between components in order to benefit the distributions is a hard sell, I know. However, the more reverse dependencies a package has, the cleaner it needs to be. This approach hard-codes that requirement and ensures that upstream is prevented from an otherwise tempting (but lazy) approach of changing "internal" APIs without due consideration. I have implemented this approach previously (outside Debian, as this particular upstream was all proprietary code) and it works well - providing that upstream make the commitment to a stable API. It has other advantages too: 0: upstream only need to release the components which have changed. 1: a stable API helps other teams develop other add-ons and components 2: it gets back to the Unix philosophy of one tool doing one job - at the source level. 3: It supports a layered test approach - the components which haven't changed only need to be tested against how those components interact with components which have changed, not against every possible permutation as you have to do with a single source package built into separate binaries. 4: It allows components to mature at different rates and focuses effort on only the active parts. Inherently, it encourages upstreams to act like distributions - not monolithic but modular. It is hard to do during rapid development but then it also requires a level of consistency and resilience which can be extremely valuable during rapid development to provide insurance against regressions. Like many methods, it is a lot easier to put into place at the start of a project but a resolute team can impose such an API later quite effectively. > IMHO: None at all. Instead it creates busy-work, and a testing > headache because you can't depend on a definite version of > $OTHER_BINARY any more. ... stable API .... Let nobody say this is impossible - I've done it, more than once. (I do try not to recommend methods which I haven't personally demonstrated working.) Monoliths are bad, we know this, that's why we are package maintainers. We know the benefits of multiple binary packages - we also need to convince some upstreams to release multiple source packages. (Equally, there is an argument for not having endless tiny packages, so don't take this approach to the opposite extreme.) -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpxD0dtzkJYZ.pgp
Description: OpenPGP digital signature