[Fedora-packaging] code vs. content

Yaakov Nemoy loupgaroublond at gmail.com
Sun Nov 22 20:57:07 UTC 2009

2009/11/22 Toshio Kuratomi <a.badger at gmail.com>:
> On Sun, Nov 22, 2009 at 03:05:49PM +0100, Yaakov Nemoy wrote:
>> 2009/11/21 Toshio Kuratomi <a.badger at gmail.com>:
>> >One technical point -- I don't think that Fedora rpm packaging is really the
>> >right technology for this.  I don't think it scales to what we want.  I
>> >don't know of any code-oriented packaging that would.
>> >
>> Point taken. Can we agree this is just a technical issue though?
> For me the big thing is the technical issue.
>> >
>> >Is content useful?  Yes, I think so.  Should there be free software means of
>> >delivering content to others, yes I think so.  Should there be a way to manage
>> >content on your computer?  Yes, I think so.  Is rpm packaging the right way
>> >to do that?  No, I don't think so.  Is the Fedora Project a venue where we
>> >can try to launch a free software means of doing this?  I do think it fits
>> >in with our mission.  I'm unsure of the overall benefit to our users (there
>> >*are* definite benefits in certain areas -- like being able to search Project
>> >Gutenberg, use a netbook like an ebook reader, have data for mapping
>> >software, etc)  however, there might be other, distro neutral projects that
>> >we should work more closely with to achieve these goal -- for instance,
>> >partner with open street maps to let people upload and share mapping
>> >information there but provide a standard location for it to be on the
>> >filesystem, help code libraries and APIs to search and download them from
>> >the network to the local machine, and building desktop tools that use that
>> >information.
>> I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative.  I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end.
> Possibly.  But this is one which requires large amounts of non-coding
> skills.  It's not about pure code here.  There's a need to build something
> that crosses several different upstream projects.  The data provider is the
> best place to host "packages".  The other unixy distros need to be consulted
> to agree on where to put the files.  Various desktop environments need to be
> influenced to agree on an API that the tools they promote can use.
> Actual coding parts of the project would be the library to access the data
> and creating the infrstructure upstream to take submissions of new data,
> search their data, and make sure their data can be retrieved
> programmatically (and scalably).

Depends on how the project is done. I'd rather take on a project with
a new comer that is willing to work with both sides of the angle.

I see a number of issues here. We need to decide how to take in
various kinds of media, pictures, icons, annoying bleeps and bloops
for the desktop, creative works such as window manager themes, and so
on. We need to decide how to store it. How to deliver it to a
particular machine (KDE has a decent example of this where you can go
online to get new wallpaper). A way to manage the content stored on
the machine. A way to mass deploy content. A way to manage
'collections' such as themes. All the nitty gritty file system
details. How to do things system wide. Per Distro. etc...

Part of this is just saying, 'we need', in a very general purpose
manner, 'a system for sharing "content" that goes beyond packaging',
and listen to the newcomer, potentially a GSoC student, to propose a
plan that works.

But that's my 0.02 cents.


More information about the Fedora-packaging mailing list