[Fedora-packaging] code vs. content
a.badger at gmail.com
Sun Nov 22 16:34:15 UTC 2009
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
> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Fedora-packaging