packaging September 2008

packaging@lists.fedoraproject.org

29 participants
19 discussions

Start a nNew thread

Are there *any* guidelines for what "Group:" an application should go in?
by Vasile Gaburici 18 Sep '08

18 Sep '08

Furthermore, are there any guidelines for the creation of new groups?

3 3

rpmlint non-standard-[ug]id, non-standard-dir-perm
by Chuck Anderson 17 Sep '08

17 Sep '08

I'm packaging cricket and rpmlint complains: cricket.noarch: W: non-standard-uid /etc/cricket/config/Defaults cricket cricket.noarch: W: non-standard-gid /etc/cricket/config/Defaults apache cricket.noarch: W: non-standard-uid /etc/cricket/config cricket cricket.noarch: W: non-standard-gid /etc/cricket/config apache cricket.noarch: E: non-standard-dir-perm /etc/cricket/config 0771 cricket.noarch: W: non-standard-uid /etc/cricket cricket cricket.noarch: W: non-standard-gid /etc/cricket apache cricket.noarch: E: non-standard-dir-perm /etc/cricket 0771 cricket.noarch: W: non-standard-uid /etc/cricket/cricket-conf.pl cricket cricket.noarch: W: non-standard-gid /etc/cricket/cricket-conf.pl apache cricket.noarch: W: non-standard-gid /var/log/cricket cricket cricket.noarch: E: non-standard-dir-perm /var/log/cricket 0775 cricket.noarch: W: non-standard-uid /etc/cricket/subtree-sets cricket cricket.noarch: W: non-standard-gid /etc/cricket/subtree-sets apache cricket.noarch: W: non-standard-uid /var/cache/cricket apache cricket.noarch: W: non-standard-gid /var/cache/cricket cricket cricket.noarch: W: non-standard-gid /var/lib/cricket cricket cricket.noarch: E: non-standard-dir-perm /var/lib/cricket 0775 What is the rationale for these warnings and errors, and why should the package avoid using them?

3 2

Re: [Fedora-packaging] Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8)
by Pavel Shevchuk 16 Sep '08

16 Sep '08

I am author of that spec. Gentlemen, start your flamethrowers. =) Text was taken from http://www.enlightenment.org/p.php?p=about/e17&l=en , which is description of product by its developers, published on official website of project. I will shorten description in CVS, but i don't think this cosmetical change is worth pushing another update. Comments are welcome, i joined this list now. -- http://scwlab.com

4 4

Packaging mono - RFC
by Paul F. Johnson 16 Sep '08

16 Sep '08

Hi, Mono (and mono-packages) are currently packaged to %{_libdir} as per the published guidelines for packaging. There has been discussion, both recently and in the past, about moving mono to .noarch packages and placing them in /usr/share. The rational behind this is that .NET CIL is a non-architecture specific system which calls on a central repository of dlls held within GAC. It is a shared resource rather than a platform specific resource. It is also not a traditional library (.so). While there is no arguing that .so (and standard linux library files) should remain in %{_libdir}, non-native libs should not live there; it pollutes and causes problems elsewhere. Simple example, if you live on a 64 bit box and install a prebuilt 32 bit app, it will look for files from GAC in /usr/lib. There is no guarantee that GAC will be found. By placing files in /usr/share GAC can always be found. Obviously this is in discussion now (which is why I've invited Andrew Jorgensen from Novell to take part in the thread), but it would certainly make more sense to have them as .noarch packages and in /usr/share. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

4 3

Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8)
by Thorsten Leemhuis 16 Sep '08

16 Sep '08

Hi all! just noticed this: On 14.09.2008 08:51, updates(a)fedoraproject.org wrote: > -------------------------------------------------------------------------------- > Fedora Update Notification > FEDORA-2008-8052 > 2008-09-13 04:56:07 > -------------------------------------------------------------------------------- > > Name : enlightenment > Product : Fedora 8 > Version : 0.16.999.043 > Release : 3.fc8 > URL : http://enlightenment.org/p.php?p=about/e17&l=en > Summary : Enlightenment DR17 - a next generation desktop shell > Description : > Enlightenment 0.17 is the next generation of UNIX graphical environments. It is > not just a window manager, but it is also a desktop shell. A desktop shell > means, a window manager plus a file manager, plus configuration utilitys all in > one. They are not separated as usual. > > Enlightenment is fast. No, really. It's fast. It is known to run on very slow > machines (like 100 Mhz CPU, 64 MB of RAM) well. So you really don't need a > modern desktop to see some eye-candy and to use a modern graphical environment. > Even more – you can control how fast you want it by using it's Performance > configuration panel to change the cache settings and more. > > The high performance does not mean that there is no eye candy. There is eye > candy that you have never seen before. Starting from the animated boot screen, > to continue with the all animations and effects that themes could provide, to > end up with fancy animated backgrounds. But not some huge .GIF files, but > really nice animations. Every virtual desktop (at the moment you can have 24) > can have it's own background (animated or not), so you can put different > wallpapers on the different virtual desktops. There are a number of effects > that can be shown when you switch from the different virtual desktops. The > menus, the borders and all other usual parts of a normal window manager are > animated as well as some of the widgets (the sliders, for example). Remember > that those effects are provided by the theme, so every theme makes E to look > different, with different effects, look and feel and animations. > > As we already mentioned, E17 provides a file manager as well. Of the time of > writing, it is not completed and is in active development (as E17 as a whole > itself), but after it is finished it will be a very nice, configurable and eye > candy. Even right now, you can do the basic things with it – browse, copy, > move, delete files. It will provide thumbnails for your pictures and will be > able to open your files with the coresponding application of your choice. > > E17 is highly configurable. Currently it has a nice configuration panel with > dialogs for all kinds of things. You can change your wallpaper or your theme, > your fonts, your screen resolution, your screen's power settings, your keyboard > and mouse settings, the language that Enlightenment talks to you, and so on. > You can contol almost every apsect of what E is doing and how. It will do what > you want it to do. > > As you already know, Enlightenment 0.17 has lots of features, but one of the > most important is, that you can add and remove functionality by using modules. > Modules are small applications that extend E17. There can be modules tho show > you the weather outside, or calendar modules, or modules to control your volume > or whatever you may think. Developing a module is not that hard, so, if you > have programming skills, you are more than welcome to develop and maintain some > modules for the community. Wow, that's a really long description. (1) Is that really needed? Do we want that? I tend to say "no" -- a description with maybe 10, 15 or 20 lines with 80 chars per line should be enough, as everything else often takes way to much time to read for the user and thus it in the end might be more confusing and time-wasting than helpful. (2) Quoting some things from above description again: > Enlightenment 0.17 is the next generation of UNIX graphical environments. [...] > Enlightenment is fast. No, really. It's fast.[...] > [...]after it is finished it will be a very nice, configurable and eye > candy.[...] Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top. Note: both things are not that important. But I found them odd and thought it might be a good idea to might bring them up here. CU knurd P.S.: Review bug for enlightenment: https://bugzilla.redhat.com/show_bug.cgi?id=448337 P.P.S.: Nice to finally see Enlightenment in Fedora :-)

8 12

Re: Long and "advertising" descriptions
by David A. Wheeler 15 Sep '08

15 Sep '08

The existing description for enlightenment is clearly too long and advertizy, and saying something is the "best" is meaningless ad puff. But... if there's more than one package that does a function, I'd like _some_ way of distinguishing one from the other. E.G., does this package strive to fast? small? featureful? interoperate with everything in the known universe? A sentence or two about a package can help people avoid a lot of work to evaluate a package that really isn't appropriate to their purpose. So to this: > > == Descriptions == > > Your package description should contain useful data about the package, > > and answer the question "what is this and what does it do?". In general, > > the description should not exceed 10 lines or so. Try not to put too > > much here, this isn't an epic novel, it's just a package description. > > Also, there is no real need to "advertise" the package here, so > > statements like "this is the best perl module that has ever been created > > by humans", while possibly accurate, are not terribly useful in > > answering the question "what is this and what does it do?". I propose adding something like this: If the package has a particular advantage over similar packages, state that factually, clearly, and briefly, to help users decide if this package is right for them. Possible advantages include good performance, smallness, quantity of features, unique functions, configurability, and interoperability. Avoid meaningless terms like "very" or "best". The description should not look like an advertisement. --- David A. Wheeler

1 0

Using newish rpm features in Fedora buildsys
by Ville Skyttä 07 Sep '08

07 Sep '08

Hi, I ran into a "make srpm" issue in the buildsys (again, seen them before every now and then) because I was using a feature in the specfile that is not supported by the version of rpmbuild that gets run with "make srpm" there. https://fedorahosted.org/fedora-infrastructure/ticket/817 I suppose there are a lot of contributors that are not aware of this, so it (along with some details exactly what to expect to (not?) work, maybe from someone from the infrastructure team who knows the details) could be a worthy addition to somewhere in the package maintainers documentation section in Wiki. Main packaging guidelines?

1 0

combining code from GPLv2 and Artistic (Perl)
by Chuck Anderson 04 Sep '08

04 Sep '08

I'm working on packaging perl-RT-Client-REST, a Perl module from CPAN. It claims to be under the Perl license (GPL+ or Artistic) except for one class, RT::Client::REST, which it claims is under the GPL since the author copied those bits from RT, which is in fact under GPLv2 according to the web site: http://code.bestpractical.com/project/RT (Request Tracker) Should the License tag be: License: (GPL+ or Artistic) and GPLv2 or just: License: GPLv2 or perhaps: License: GPLv2 or Artistic ? The README says: ... Author: Dmitri Tikhonov <dtikhonov(a)yahoo.com> RT::Client::REST is based on 'rt' command-line utility distributed with RT 3.x written by Abhijit Menon-Sen <ams(a)wiw.org> and donated to RT project. License: Original 'rt' utility is GPL, therefore so is RT::Client::REST. The rest of the modules are licensed under the usual artistic license. (I am not sure it makes sense to do this. Does GPL override artistic license? Someone let me know if you have a definite answer.) The source code mentions that RT::Client::REST is under GPL: ./lib/RT/Client/REST.pm:=head1 LICENSE ./lib/RT/Client/REST.pm:Since original rt is licensed under GPL, so is this module. ./lib/RT/Client/REST/Queue.pm:=head1 LICENSE ./lib/RT/Client/REST/Queue.pm:Perl license with the exception of L<RT::Client::REST>, which is GPLed. ./lib/RT/Client/REST/Attachment.pm:=head1 LICENSE ./lib/RT/Client/REST/Attachment.pm:Perl license with the exception of L<RT::Client::REST>, which is GPLed. ./lib/RT/Client/REST/Transaction.pm:=head1 LICENSE ./lib/RT/Client/REST/Transaction.pm:Perl license with the exception of L<RT::Client::REST>, which is GPLed. ./lib/RT/Client/REST/User.pm:=head1 LICENSE ./lib/RT/Client/REST/User.pm:Perl license with the exception of L<RT::Client::REST>, which is GPLed. ./lib/RT/Client/REST/Ticket.pm:=head1 LICENSE ./lib/RT/Client/REST/Ticket.pm:Perl license with the exception of L<RT::Client::REST>, which is GPLed. AFAICT these are where the RT::Client::REST class and derived classes are defined: ./lib/RT/Client/REST.pm:package RT::Client::REST; ./lib/RT/Client/REST/Queue.pm:package RT::Client::REST::Queue; ./lib/RT/Client/REST/HTTPClient.pm:package RT::Client::REST::HTTPClient; ./lib/RT/Client/REST/Forms.pm:package RT::Client::REST::Forms; ./lib/RT/Client/REST/SearchResult.pm:package RT::Client::REST::SearchResult; ./lib/RT/Client/REST/Object.pm:package RT::Client::REST::Object; ./lib/RT/Client/REST/Object.pm: package RT::Client::REST::MyType; ./lib/RT/Client/REST/Attachment.pm:package RT::Client::REST::Attachment; ./lib/RT/Client/REST/Transaction.pm:package RT::Client::REST::Transaction; ./lib/RT/Client/REST/User.pm:package RT::Client::REST::User; ./lib/RT/Client/REST/Ticket.pm:package RT::Client::REST::Ticket; ./lib/RT/Client/REST/Exception.pm:package RT::Client::REST::Exception; ./lib/RT/Client/REST/Object/Exception.pm:package RT::Client::REST::Object::Exception; Thanks.

2 1

Revised Haskell Guidelines 2008.08.13
by Yaakov Nemoy 01 Sep '08

01 Sep '08

Hi Lists, I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee. As follows is a list of the issues I've heard, and how they are fixed. * %buildsubdir is not a common way of doing things ** we need this macro in the install phase to get at the working dir we used to compile the package. This was only needed by the rather scary looking file seeking code, so I put it into a macro that is called by another macro, and hid it from public view. The user should not need this in the spec file anymore. * this looks scary, use macros ** done, the guidelines include them * how do runtime requirements work, vis a vis build time, etc... ** GHC apparently uses static linking for haskell libraries and dynamic for C libraries. *** This is quite similar to OCaml ** all the dynamic links to C libraries can be automagically detected by RPM's wonderful automagic. ** the -devel packages still need to be put in by hand in the BuildRequires ** most packages only need their dependency libraries at build time. ** Some packages, notably xmonad, do code generation and require the dependencies at run time. *** the packager is responsible for tracking this bit * this file detection stuff is scary ** I've put it into a series of macros and documented it * this register stuff looks kinky ** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, whcih it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it. Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadeline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later. -Yaakov

7 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2008