Source-code package management

[Norman Feske]

Hi Lonnie,

first, would you mind joining the discussion at the issue tracker so we
have a single place where all information is gathered?

> Source code repositories, package management and application
> dependencies are a huge challenge in the current age of end-users and
> developers alike.

I agree. So let us take one step at a time. The topic discussed in issue
#1082 is about the mechanism to incorporate 3rd-party upstream source
code with Genode's source code. I'm afraid naming the topic "package
management" was a bit misleading, sorry.

Let us leave the "packaging" of Genode software ("package" as in
container file for distribution) for later.

> I have seen many efforts in these areas, and there
> does not seem to be a "best" solution that works for everyone.
> 
> On the developer side, I am a proponent for hierarchical tree structures
> in which you keep the main system components distinctively separated
> from things like 3rd part applications and the like.

Yes. This is exactly the motivation behind my suggestion (insertion of a
"repos/" subdirectory) in the discussion in issue tracker.

> I'm sure that this is not the best structure and layout, but the idea is
> that it keeps the Genode and the particular kernel completely separated
> from 3rd party apps and ports. This way you always know what the
> "system" needs for it basic minimal build a opposed to intermixing the
> drivers, libs, and applications like in other OS distributions.
...
> Also, one thing that I really find bothersome in other OS distributions
> is that they tend to add all of the various system files together into a
> mess of files.
> 
> What I mean is that, for example, linux and windows will put application
> libraries mixed in with system libraries, and the like. This really
> makes a mess in the filesystem which promotes things like zombie
> libraries and configuration files, etc.....

I think we need to clearly distinguish the layout of a file system of an
installed Genode-based OS and the layout of the source tree. Both
layouts must satisfy different requirements.

I agree with your latter statement when referring to the layout of an
installed OS. But within the source tree, there is no clear distinction
between library code, application code, driver code, etc. For example,
the FUSE-based file systems can be used as libc plugin (a library) or a
service (a separate program). In many cases, components use intermediate
libraries as a way to separate platform-specific parts from the main
application (looking at the dynamic linker or the timer). Consequently
there is no useful source-tree structure that separates libraries from
components.

Genode's structure based on so-called repositories fosters the
separation of lower-level from higher-level code. E.g., 'os' depends on
'base' but not vice versa. So when working on a topic, the developer has
to make the conscious decision at which level his software resides.

Keeping our genuine source code separated from imported 3rd-party code
is definitely desired. This is currently not the case. So we should
improve the current state.

> Perhaps one idea, might be to think about the way that "portable"
> applications are packaged in that they typically keep almost all of
> their needed libraries with the application that uses them. This could
> be good from the standpoint of different application versions needing
> different versions of the same libraries because they would be stored
> with the application and not the OS.
> 
> Also, the OS would not continue to grow to an unmanageable size due to
> application installations. This would allow for tighter control of the
> OS and its needed libraries, drivers, etc....
> 
> Just my opinion though and I am sure that there may be even better
> solutions than I have mentioned here, but currently, I advocate the
> Gentoo Portage (emerge) and Portable Applications approach as a possible
> solution.

All what you say resonates well with me. However, at this point, I'd
prefer to focus the discussion on the source-code management.

Thank you for sharing your ideas! See you at the discussion thread at
GitHub? ;-)

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth