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

Re: Would like to import CORE into Fedora (naming problem)



On Thu, 14 Sep 2006 06:03:58 +0200, Ralf Corsepius wrote:

> On Wed, 2006-09-13 at 19:42 -0700, Chris Weyl wrote:
> > On 9/13/06, Michael Schwendt wrote:
> > > On Wed, 13 Sep 2006 23:43:35 +0200, Denis Leroy wrote:
> > >
> > > > But yeah, probably not worth the effort. I don't see much wrong with
> > > > having /usr/include/CORE around either...
> > >
> > > Except that the name is very generic and hence short-sighted.
>
> Agreed, it's very short-sighted, because "CORE" is not unlikely to
> conflict with "core dump files" on certain systems or with "CORE-files"
> an OS provides.
> 
> > Isn't that an upstream issue?  Do we have an actual conflict in /usr/include?

It is a matter of perspective.

If you encountered a package which put a hundred files directly into
/usr/include, what would you think first?  "Does it conflict already?"
Or: "Is it really necessary to pollute the standard search path? Doesn't
this increase the risk of creating a sudden conflict?" What if the files
were named /usr/include/core.h, /usr/include/Core/ or /usr/lib/libcore.so.1
and did not yet conflict?

I don't say this directory /usr/include/CORE is an immediate reason not to
accept this package in FE for now and for the supported platforms.
Nevertheless it is terribly poor naming for a directory. The library is
called just "Core Library", the project "CORE". Ugh.

The review process not only asks reviewers to check a list of MUST/SHOULD
items. It also asks reviewers to take a look at an RPM package. If the
reviewer finds pitfalls or forms of ugly packaging, it sometimes leads to
a feeling like "well, sure, the packager managed to wrap the software into
an RPM package or many, but I'm not fond of the spec or the binaries and
hence I wouldn't feel good when approving this".

This is because the review system is not bullet-proof in that it covers
all possible packaging issues. It is not that if a package meets the
guidelines it is "perfect" and forward-looking.

> Not ATM, but do we have a conflict
> on /usr/include/LINUX, /usr/include/LOST+FOUND, or /usr/include/NFS? No.
> 
> That's the problem behind of complaints on "generality in file names",
> it's a matter of perspective, taste and foresight.
> 
> Ralf
> 
> 


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