On Fri, Feb 20, 2009 at 08:21:23AM -0600, steve@xxxxxxxxxxxx wrote: > > a. Naming pacakges is going to be tough, because books have long titles, > such as cory doctorow's, do acronyms make sense ? This is not an easy issue, because, contrary to software there is no convenient name that upstream choosed. So the packager is left with too much choice and contradictory objectives. * short names are better * content needs to be disambiguated from software and other content with different medium and same title * the name should allow to find which content it is as best as possible Other issues arise, what about different languages, different formats? > b. Version numbers do not make sense for content that is not versioned If the author has a versionning scheme that looks ascii ascending lets use it. Otherwise I think that the following would work Version: 0 Release: 0.X.YYYYMMDD with YYYY year, MM month and DD day (I'd do the same for a software without version, and it is indeed what I used for uread) for the document date of publishing, or of access if publishing date is not known. > 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. Not an issue here, and it is the same than with forks that are both interesting (like xemacs and emacs). > 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). Not an issue. At least ncarg (or ncl) was like this and is in fedora. I think that the NonCommercial clause makes it not suitable for a fedora content repo, however. (not modifiable would be fine, in my opinion, but not noin commercial). > 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. I think that there are books that fit in fedora and not in a separate repo. For example, the 'maximum rpm book', but also books that explains how to configure servers, or the svn book http://svnbook.red-bean.com/ Also videos closely realted with fedora should in my opinion be directly in fedora, like videos explaining how to use a given application. Books about programming are less obvious candidates to be directly in fedora, but still good candidates in my opinion. -- Pat -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
