xorg-x11- packaging prefix

Nicolas Mailhot nicolas.mailhot at laposte.net
Tue May 9 06:31:24 UTC 2006


Le mardi 09 mai 2006 à 07:40 +0200, Thorsten Leemhuis a écrit :

> > Addon Packages (General)
> > If a new package is considered an "addon" package that enhances or
> > adds a new functionality to an existing Fedora Core or Fedora Extras
> > package without being useful on its own, its name should reflect this
> > fact.
> > 
> > The new package ("child") should prepend the "parent" package in its
> > name, in the format: %{parent}-%{child}
> 
> There is more in the wiki. Yes, I know that some people don't like this
> scheme. But at least one general scheme is better than a lot of
> different schemes.

I'm afraid there is no general case. The wiki can say whatever it wants,
wiki-produced prefixes are so far much less numerous than existing
prefixes.

And a lot of the time existing prefixes are careful like in the xorg-x11
case about where they lay the blame. When you maintain a large set of
packages you absolutely do not want your relations with upstream to sour
because someone misled by package names complained at their door
(another reason is different orgs follow different conventions, you may
repaint a package with a common prefix it will still feel alien to the
user if it's produced by someone else) 

Like I wrote before, java packages for example follow the same
convention as the xorg packages. I'd be very careful not to ignore the
reasons people who actually had to maintain large numbers of related
packages for several years choose the existing de facto namespace rules.
I'm far from sure the current FE rule has carefully balanced ls
convenience with long-temr packaging convenience

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060509/be45cc9c/attachment.sig>


More information about the fedora-devel-list mailing list