[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpms/yumex/devel yumex.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2



On Tue, 21 Jun 2005 19:09:32 -0700, Michael A. Peters wrote:

> > > Requires: yum >= 2.3.2
> > > Requires: pygtk2
> > > Requires: usermode
> > > Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]")
> > 
> > python(abi) = ... dependency is automatic since FC4. For FC3, this
> > package won't work anyway, because of the required Yum version.
> 
> So that should be removed?
> The package is only suppose to target FC4/devel

A common problem with explicit versioned dependencies is that they
increase the likelihood of breaking things, but only add little value.
Unless there is reason to add them. Yumex is noarch. It does not depend on
any specific Python module paths. It does not require any versioned
/usr/bin/pythonX.Y interpreter binary either. It depends on "yum" already,
which in turn requires quite some Python stuff including a specific
python(abi) version.  If there is reason to assume that a new Python
version breaks yumex, add the dependency. Else, it doesn't add any value.

Requires: python(abi) = %(%{__python} -c "import sys ; print sys.version[:3]")

With a distribution upgrade of Python which introduces a new ABI, such a
dependency would not "fix" anything. Only a rebuild of yumex would do.

On the contrary, if an explicit dependency causes additional packages to
be installed which would not be installed otherwise, that's a useful case.

> > > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
> > 
> > D'oh! What makes these checks come back from time to time?
> 
> I thought that was a matter of packager preference.

They still only decrease readability.
 
> > > desktop-file-install --vendor fedora --delete-original \
> > >     --dir $RPM_BUILD_ROOT%{_datadir}/applications \
> > >     --add-category X-Red-Hat-Base \
> > 
> > It's not a preferred Core application and hence must not add
> > category X-Red-Hat-Base. Category X-Fedora is fine, although it's
> > not evaluated anywhere.
> 
> X-Fedora is specified as being required here:
> http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines
> 
> "Additionally, all Fedora packages must contain the "X-Fedora"
> category."
> 
> X-Red-Hat-Base noted.

We add X-Fedora, but it is not used by any graphical desktop menu
system like X-Red-Hat-Base/X-Red-Hat-Extra was/is used to distinguish
between creating an upper-level menu or sub-menu, respectively.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]