[Fedora-packaging] I wish to package some CC licensed content ...

[steve at lonetwin.net]

Hi Patrice,

Thanks for your comments.

Quoting Patrice Dumas <pertusus at free.fr>:

>> I like this idea and I was thinking along the same lines. In addition to
>> this, I was thinking about making the rpms relocatable, so that if a user
>> prefers, the rpm could be installed under
>> ~/fedora-cc/{books,music,video,...}[2] ...etc.
>
> I don't know if this level of detail is wanted right now, but using
> fedora-cc is not a good idea, in my opinion, it should be something more
> neutral, that can be also used in other distros, or become part of the
> FHS, so something along
>
> %{_datadir}/content/{books,music,video,...}

Yes, that's what my footnote [2] wanted to convey

>
> About relocatable packages, I don't think this is very important. Pure
> content packages will be relocatable, sure, but I don't think this should be
> a goal.

Agreed.

>
>>> One consideration would be to have a fedora-cc-menus similar to
>>> games-menus, that would make sure any contents appear in a reasonable
>>> place in a user's applications menu.
>>
>> This is a good idea too ! Thanks !
>
> I don't think such thing should be done outside of Fedora, I mean, all the
> guidelines for content only packages should also be Fedora guidelines.
>
> So this is a more general issue of having a specific menu for content,
> which is, in my opinion, of relevance for fedora and even for freedesktop.
>

Agreed.

>> Anyway, here is what I plan on doing:
>> - Create a set of packaging guidelines for myself, so that i am
>> consistent in creating the specs
>
> I think that you should really use the Fedora guidelines, and help enhancing
> Fedora guidelines for content that is acceptable in Fedora (like computer
> related books, for example, or videos, that are tied enough with Fedora or
> linux). And then you would use those guidelines for this repo (this doesn't
> preclude making a document that only holds the guidelines relevant for
> content that should be much simpler).

Ok, let me clarify. I think my post gave the impression that i was all  
charged up to do something new all by myself and unrelated to fedora.  
This is not the case. The rpms i created and the repo setup was more  
of a 'proof-of-concept'. I just wanted to see for myself, whether it  
was worthwhile to 'shoehorn' content in a software package  
management/distribution tool. For instance, i learned the following  
this:

a. Naming pacakges is going to be tough, because books have long  
titles, such as cory doctorow's, do acronyms make sense ?
b. Version numbers do not make sense for content that is not versioned
c. How does one treat remixes (ie: content that has been modified and  
re-released by someone else). This is going to be different than  
software, because, the ^upstream^ are more likely to *prefer* the  
forks (so to say) to live side-by-side with the originals than  
discourage it.
d. Is it acceptable to distribute content like this:  
http://ghosts.nin.com/main/order_options

where although the content is licensed under a share-alike license[1],  
the actual way to get the content is to provide an email where a  
'one-time download' link would be sent. So, that implies, we get  
around the spirit under which the content is being shared (assuming  
the sole intention of this policy was to track downloads).

[1] http://creativecommons.org/weblog/entry/8095

So, I agree, that using the existing guidelines makes sense, and that  
was what i intend to do, my experiments were just that -- experiments.  
My Todo list was mentioned under the assumption that this is not  
something Fedora would see as a good fit 'within' the distribution  
itself.

I'd be very pleased if my assumption is wrong.


>
>> - Explore the possibilities offered by yum (yum plugins ??) to be able to:
>>     + customize the install location of the content
>>     + pay attention to the 'Group' header for group installations,
>> instead of needing a comps.xml
>
> I don't think this should be a specific goal of the project.

...but I do want to separate content from code. So, for example, on  
installing say yum-content-plugin would one be able to yum grouplist  
"music/nin"

of course, yum search "nin" would also do, so no big deal.

>
>> - Create some rpms, buy a domain name (any suggestions ??), set up the
>> repo and announce a beta :) !
>
> Still in my opinion, I think it would be better first to submit to Fedora
> content only packages that are acceptable in Fedora. And when the guidelines
> are fleshed out, do your own repo. It sure can be done in parallel, if some
> guidelines cannot be tested in Fedora anyway.

Umm, ok.

>
>> - These might be totally crazy ...they are just idle thoughts as of now:
>>     + Explore if rpm allows for customization of headers, so that we may
>> better describe the content
>>     + Understand the rpm format so that we can build rpms by just slapping a
>>     rpm header to a (cpio ??) archive instead of ^building^ (ie:   
>> going through
>>     the motions of %prep, %build, %install ..etc) an rpm.
>
> I don't think you should do that, at least not in a near future. Setting up
> the repo with classical rpmbuild should be enough (and should be simpler than
> setting up a normal build system since all the rpms should be noarch).

Yeah, like I said, those sound crazy ...so, it wasn't something I  
would've bothered with right away.

>
>> PS: like i mentioned in my previous post, if people here think this
>> discussion is off-topic, we can move it someplace else.
>
> I think that this is on-topic, and that guidelines for content could  
>  be of use
> in fedora.

Cool !

>> [1] Just these rpms actually:
>> Advanced Linux Programming - alp-1.0-1.fc10.noarch.rpm
>> Code Listings from Advanced Linux Programming -
>> alp-listings-1.0-1.fc10.noarch.rpm
>> Linux Device Drivers, Third Edition - ldd3-pdf-3-1.noarch.rpm
>
> I think that those may be in fedora proper, but I am not sure. Maybe somebody
> more knowledgable of the code vs content issue could say.

Yes, i think i'll submit those anyways and see what they say on the BZ.


cheers,
- steve