rpmlint non-standard-[ug]id, non-standard-dir-perm
by Chuck Anderson
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?
15 years, 7 months
Packaging mono - RFC
by Paul F. Johnson
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!
15 years, 7 months
Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8)
by Thorsten Leemhuis
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 :-)
15 years, 7 months
Re: Long and "advertising" descriptions
by David A. Wheeler
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
15 years, 7 months
Using newish rpm features in Fedora buildsys
by Ville Skyttä
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?
15 years, 7 months
combining code from GPLv2 and Artistic (Perl)
by Chuck Anderson
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.
15 years, 7 months
Revised Haskell Guidelines 2008.08.13
by Yaakov Nemoy
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
15 years, 7 months
