Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-10 Thread Robert Bridge
On Tue, 10 Jun 2008 02:58:54 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

  Well, in general, if you rely on extensions changing every time a
  program cannot deal with a new feature of a file format, it would be
  quite crazy.  For example, if C programs had to start using .c-2,
  .c-3, etc., it would get ugly fast.
 
 Which is why programs that use any major C feature introduced since
 1980 use the extension '.cc' or '.cpp'.

Except any program using .cc or .cpp for code is liable to break on
gcc, as they are C++ file extensions, and to the best of my (admittedly
limited knowledge) C and C++ are distinct languages...

So relying on the file extension seems to be a recipe for
misunderstanding. Why limit the functionality of the package manager to
rely on the file names? How do you protect the package manager from a
malicious ebuild masquerading under the wrong EAPI? Relying on the file
name for information is the kind of design decision we laugh at in
Windows, so why adopt it here?
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-10 Thread Ciaran McCreesh
On Tue, 10 Jun 2008 15:36:58 +0100
Robert Bridge [EMAIL PROTECTED] wrote:
 So relying on the file extension seems to be a recipe for
 misunderstanding. Why limit the functionality of the package manager
 to rely on the file names? How do you protect the package manager
 from a malicious ebuild masquerading under the wrong EAPI? Relying on
 the file name for information is the kind of design decision we laugh
 at in Windows, so why adopt it here?

There is no protection against malicious ebuilds. Malicious ebuilds
already run code as root when you install them. Being able to get an
ebuild run with the wrong EAPI is utterly irrelevant.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-09 Thread Joe Peterson
[EMAIL PROTECTED] wrote:
 1) Increase of [needless] complexity in filenames/extensions (and only one
   example of the impact is that searching for ebuild files becomes less
   straightforward), when things like SLOT, EAPI, etc., etc., seem to
   naturally belong as part of the script contents/syntax.
 
 Okay... so:
find /usr/portage -name *ebuild
 
 becomes:
find /usr/portage -name *ebuild*
 
 That doesn't seem that much harder to me... Same for the file detection 
 for editors.

I'm not saying it's a lot harder.  But it is more complex and less
elegant.  Also, it is error-prone.  If someone, by habit, looks for all
*.ebuild, he will miss a portion of the ebuilds and not even realize
it at first (or ever).

 2) Having the same info in more than one place is generally a bad idea in
   any design - this is true in any discipline. [...]
 
 If you read the proposal more closely, you would notice that it 
 specifically says to *not* specify EAPI in more than one place. It belongs 
 solely in the filename suffix. The only reason the EAPI variable would be 
 recognized inside the file itself is to allow for backwards compatibility 
 with the current way EAPI=1 is done -- this behavior would be discouraged 
 in all future ebuilds.

Still, the GLEP addresses the very point of what logic has to be
followed if the EAPI exists in the filename, in the file, or both.  It
talks of pre-source EAPIs and post-source EAPIs.  Complicated.

 3) It uses the extension in a way that goes against common use in computers,
   especially *nix.  No longer could we then say that a file of type
   Gentoo ebuild has the extension ebuild
   (simple/straightforward/standard).
 
 In most unixes, the file extension is completely meaningless. What matters 
 is the contents of the file. Nautilus, etc, mostly use detection based 
 upon the files contents to identify file types (at least for local files), 
 not file extensoins.

That wasn't the point I was trying to make.  I am not saying that the
extension has special meaning (even the . has no meaning, really, in
unix) to software.  I mean that people associate certain types of files
with certain extensions.  I'm speaking more of the human interface here.

 4) It seems that the motivation for this GLEP is so that the tools can
   determine the EAPI without reading/sourcing the script.  In order to
   get around this, the GLEP suggests exposing this technical information
   in the filename.  This is the wrong place to expose it, and the reasons
   given are not that this detail should be exposed there but rather because
   it is inefficient to source the file to get the info.  So this is a case
   of trying to solve a technical issue by changing the interface.  I
   believe it would be more correct to attack the technical problem in a way
   that does not do this, and I am sure this can be solved.
 
 The reason for this is that, while the current two EAPIs don't cause 
 trouble if you try to source them when you don't support them, that 
 doesn't mean future ones won't. I'm not talking about anything silly like 
 rewriting ebuilds in python, but things like changing syntax for DEPEND 
 could potentially confuse older package managers. By adding the EAPI 
 specification to the filename instead, old package managers just plain 
 won't see packages they don't understand, so there's no need to worry 
 about this.

Well, in general, if you rely on extensions changing every time a
program cannot deal with a new feature of a file format, it would be
quite crazy.  For example, if C programs had to start using .c-2,
.c-3, etc., it would get ugly fast.  Also, it is easy to build EAPI
checking into portage now, and when the requisite time passes, you only
need to deal with situations where *very* old portage versions are still
in use.  Since portage is typically the first thing the system upgrades
after a sync, I don't see a big issue.  Or, if that is not acceptable,
see my comment at the end about a one-time change to a new extension
like .eb.

 Also, sourcing a package to extract one metadata key takes much more time 
 than just not loading it in the first place.

I understand there are technical/performance issues to solve, but this
does not, IMHO, justify moving this info into a filename/extension.

 1) Littering the filename with this kind of stuff is potentially confusing to
   both devs and users - I know it's been stated that users shouldn't care,
   but I don't think that's a good reason/assumption.
 
 New eapis aren't necessarily of any immediate use to people. Those who 
 don't see the need for them can continue to just use EAPI=0, plain old 
 .ebuild files of the sort that've been around for years, and for many 
 packages this is totally appropriate. The only devs who should care are 
 the ones who have a need for the new features.

But when they do need the new features, they need to use the new EAPIs.
 This is not a matter of degree - it is a matter of defining the
filename format. 

Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-09 Thread Ciaran McCreesh
On Mon, 09 Jun 2008 19:49:08 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
 I'm not saying it's a lot harder.  But it is more complex and less
 elegant.  Also, it is error-prone.  If someone, by habit, looks for
 all *.ebuild, he will miss a portion of the ebuilds and not even
 realize it at first (or ever).

Yes, if something changes, and people carry on doing the old thing by
habit, then things go wrong.

 Still, the GLEP addresses the very point of what logic has to be
 followed if the EAPI exists in the filename, in the file, or both.  It
 talks of pre-source EAPIs and post-source EAPIs.  Complicated.

And if the GLEP didn't address it people would complain that it allowed
undefined behaviour.

 Well, in general, if you rely on extensions changing every time a
 program cannot deal with a new feature of a file format, it would be
 quite crazy.  For example, if C programs had to start using .c-2,
 .c-3, etc., it would get ugly fast.

Which is why programs that use any major C feature introduced since
1980 use the extension '.cc' or '.cpp'.

 Also, it is easy to build EAPI checking into portage now, and when
 the requisite time passes, you only need to deal with situations
 where *very* old portage versions are still in use.  Since portage is
 typically the first thing the system upgrades after a sync, I don't
 see a big issue.  Or, if that is not acceptable, see my comment at
 the end about a one-time change to a new extension like .eb.

You completely miss the point of the GLEP. We need new extensions
precisely because current package managers can't handle future EAPIs
cleanly, and we need to carry on using new extensions because otherwise
we restrict what future EAPIs can do.

 But what users *really* don't care about is EAPIs, and this GLEP would
 expose that technical detail to them in a very blatent way.

Anyone who cares about ebuilds at a file level has to care about EAPIs.

 Along those lines, as I've said before, migrating to a new extension,
 *one-time*, as a solution to this, although not optimal, would be far
 more satisfactory than introducing a series of ever-changing
 extensions.

No it won't. It means future EAPIs will be restricted to some
particular source format.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature