[gentoo-dev] Last rites: media-sound/squeezeboxserver

2012-04-12 Thread Joe Peterson
# Joe Peterson lava...@gentoo.org (12 Apr 2012)
# Replaced by new package: media-sound/logitechmediaserver-bin
#   - Upstream retired the old package/name
# Removal in 30 days - see bug 377825
media-sound/squeezeboxserver



Re: [gentoo-dev] Suggestion to ask devs to change their bugzilla name when becoming devaway

2010-06-10 Thread Joe Peterson
I think a better solution, if we need to indicate this, is to have
bugzilla grab the status from devaway and display it next to the dev's
name in bug reports.  Changing the user's name seems a bit cumbersome,
and I don't agree that people will know what devaway means - i.e.
they may not even google it.

-Joe


2010/6/10 Pacho Ramos pa...@gentoo.org:
 Hello

 Currently, we only need to set a proper message in ~/.away (as talked in
 http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml ) when
 becoming devaway. The problem is that a lot of our users don't know
 about that devaway list and, then, they will still open bug reports and
 complaint when their reports get stalled due maintainer not being
 available.

 My suggestion (until http://bugs.gentoo.org/show_bug.cgi?id=256934 is
 solved) is to add a new step to how to use the Devaway System
 instructions asking people to also change their bugzilla name appending
 (Devaway), for example:

 Pacho Ramos would be changed to Pacho Ramos (Deavaway)

 Then, people could simply search devaway in google and would get
 proper information (gentoo devway page is the first shown)

 Thanks




[gentoo-dev] Last rites for games-simulation/secondlife

2010-06-03 Thread Joe Peterson
# Joe Peterson lava...@gentoo.org (03 Jun 2010)
# Masked for removal in 30 days:
# Fails to build with gcc 4.4 (see bug #290105)
# Requires non-open-source components that never worked well
#  - e.g. voice, media
#  - this (source) package never behaved quite like the binary
# Really should be replaced by Snowglobe, which is the OS version
# (Note: games-simulation/secondlife-bin will remain for now)
games-simulation/secondlife



Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

2010-03-31 Thread Joe Peterson
On 03/31/2010 02:18 AM, Mike Frysinger wrote:
 i'm already using ~/.forward which means mail still goes to mail.g.o and that 
 server takes care of forwarding it to my private gmail.com account.  then my 
 mail client fetches it from gmail.com via the normal pop/imap methods.  there 
 is no need to share passwords between gmail.com and g.o.
 
 so i dont see what advantage this process ive been using for years has over 
 this method.  they look pretty much equivalent.
 -mike

Hey Mike,

You are right that what you are doing gives you the ability to use gmail
for this.  However, there's one key thing that turning on Standard
Edition does:

It's a Google Apps account, not just a Gmail account.  You cannot have
more than one gmail account open in your browser at one time - the
cookies are not separate.  Whereas you *can* have your gmail and all of
your google apps accounts (in different domains) open at one time.

Those, like me, who have several google apps accounts (I have a personal
business one, a personal one, and a work one) can keep accounts separate
this way.  Also, since it's the gentoo.org google apps account, the
email address looks the same as your gentoo address (rather than
foo-gen...@gmail.com, etc.).

What Alec was asking is why not turn on the feature.  It just enables
more functionality for those who want to use it.  It just requires we
verify that we own gentoo.org.

-Joe




Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

2010-03-31 Thread Joe Peterson
On 03/31/2010 01:40 PM, Mike Frysinger wrote:
 Those, like me, who have several google apps accounts (I have a personal
 business one, a personal one, and a work one) can keep accounts separate
 this way.  Also, since it's the gentoo.org google apps account, the
 email address looks the same as your gentoo address (rather than
 foo-gen...@gmail.com, etc.).

 this too has been doable forever.  gmail has had a feature where you can set 
 the From: address to any e-maill address once you verified it was your e-
 mail address.

Well, that's slightly different.  I use that too, but it means you need
to have all your mail coming into one account.  Yes, you can send from
different senders, but if you want to totally separate your email to
your different addresses into different boxes, this won't work.  Even
labeling is not foolproof, since emails that are to lists or to bcc'd
addresses (i.e. do not contain your address in the header) cannot be
labeled accordingly.

 i'm not against the idea, i was just wondering what the point was

Cool.  :)

-Joe



Re: [gentoo-dev] RFC: Google Apps Standard Edition @ gentoo.org

2010-03-31 Thread Joe Peterson
On 03/31/2010 02:28 PM, Sebastian Pipping wrote:
 I am worried that if people start using say Google Docs for
 collaborating on Gentoo content, everyone else is forced to use Google
 Docs to participate.

Gentoo could set policies that such shared resources should not be done
via google calender, or if it is, then the calender is exported to
everyone (or piped to another ical type service where everyone can
interact).

I'm mainly interested in the ability to use the gmail interface, which
is transparent to anyone not using it.  It's just what the person who
decides to use it sees.  Just as now you can forward your incoming mail
to any server you want anyway.

-Joe



[gentoo-dev] Last rites: sys-fs/btrfs

2010-03-13 Thread Joe Peterson
# Joe Peterson lava...@gentoo.org (13 Mar 2010)
# Old, unmainted standalone kernel modules for older kernels.
# Kernels 2.6.29-rc1 and newer include integrated btrfs.
# Bug #285357 reports version 0.17 (newest standalone) does not build.
# Last rited: to be removed in 30 days.
sys-fs/btrfs


-Joe



Re: [gentoo-dev] 2009 Council Elections

2009-06-26 Thread Joe Peterson
Denis Dupeyron wrote:
 I'd be ready to believe part of it was that he wanted to
 experiment. And experiments sometimes succeed, or sometimes they fail,

Well, experimentation is OK (and I would encourage it for many things),
but I'm not sure I'd agree that experimentally giving someone council
powers for a even one meeting is wise, unless you are very sure that it
will not result in adverse decisions being made.  I'd rather see
experimentation done in other, less risky ways.

For what it's worth, I'd vote to have it codified that council members
and proxies need to be Gentoo devs (or at least a member of the project
in some capacity).  To me, it is a good minimum requirement, at least.

-Joe



Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

2009-06-08 Thread Joe Peterson
Mike Frysinger wrote:
 maybe, but since we arent going to use /libexec/ at this time, that means 
 /etc 
 is the next best place

How about /usr/share/openrc/version?

Since /usr/share is supposed to contain package-specific (but platform
independent) files that are *not* meant to be modified (unlike /etc), seems
like it might be a good place for it.

-Joe



Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

2009-06-08 Thread Joe Peterson
Mike Frysinger wrote:
 /usr isnt guaranteed to be mounted for all init.d scripts

Right...  Well, then the best choice is probably /etc out of the list [Roy
pointed out] of the only OS-nonspecific dirs, unless we want to have a small
executable script in /bin or /sbin that spits out the version.

-Joe



Re: [gentoo-dev] How not to discuss

2009-05-30 Thread Joe Peterson
Alec Warner wrote:
 Lets agree to disagree on the definition of technical then and
 instead agree that putting EAPI in the filename is a bad design
 decision (technicalness aside) and then have a beer!

Wow.  That's a *great* idea!  ;)

-Cheers, Joe



Re: [gentoo-dev] How not to discuss

2009-05-28 Thread Joe Peterson
Alec Warner wrote:
 No, it's entirely objective. GLEP 55 clearly shows how the filename
 based options are objectively better than anything else.
 
 But the decision will not be based entirely on objective merits
 (although I will concede that EAPI in filename is the 'best' technical
 choice).

(Jeez, I hate to add another to this thread, but this way of defining
'technical' bothers me)

Along the lines of what Roy so eloquently expressed, I think it's
important that we do not divorce *design* from *technical*.  The
decision of where to place the EAPI is a design issue, and many of us
here clearly believe that it is *not* good design to put this kind of
metadata in the filename.  Therefore, the statement that it is the
'best' technical choice is not objectively true.

Technical issues of performance and efficiency can be addressed when
proper design has been done beforehand.  Part of the purpose of the
implementation (after proper design is in place) is to address
performance and other related issues.  And part of the design is how we
define the *interface*.  The filename is clearly part of the interface.
 It is part of how devs (and users) interact with portage when writing
ebuilds.  Much of the argument for EAPI in the filename has been
motivated by a perceived implementation benefit of speed, as if there
were no other solutions (which is naive).  As Roy suggested, if all
engineering decisions were based purely on pragmatic ease of
implementation factors, we'd have a lot of ugly designs/interfaces out
there.

It may be easy (although incorrect) to dismiss elegance/design/interface
issues as non-technical, but I maintain they actually *are* technical
matters of great importance.  I've been an engineer for over 20 years,
and I have seen the pitfalls of taking the quick-and-dirty approach just
to slap a new feature into a software app.  I've seen how such hasty
design mistakes can cause great pain and regret for a long time after.
Let's get the design right, first.  For what it's worth, GLEP 55 does
now provide an option (#3: Easily fetchable EAPI inside the ebuild and
one-time extension change) that demonstrates good design.

-Joe



Re: [gentoo-dev] Gentoo Council Reminder for May 28

2009-05-27 Thread Joe Peterson
Roy Bamford wrote:
 GLEP 55 still confuses the problem and the solution.
 Adding metadata to the filename is not required and is bad system 
 design practice. Its also the first step on the slippery slope to 
 adding more metadata in the future.

++

 Changing the .ebuild extension, to blind existing PMs to new format 
 ebuilds, is probably a good thing as it means we can have both 
 formats in the tree at the same time and not wait a long time (year 
 plus) for users to be on a new package manager.

Also, ++

 This allows the EAPI to be included within the ebuild where it belongs.
 
 That means the EAPI needs to be extracted before the ebuild is sourced, 
 which from the figures bandied about on the list may take marginaly 
 longer but its a price worth paying for a sound system design.
 Gentoo should not repeat the VHS vs Betamax war. For those who do not 
 remember, VHS was the better marketed but inferior technical solution 
 that won the standards war for domestic Video recorders. 

:)  Yep.  And bad design decisions can haunt is for a long time.  My
preference is the one-time .ebuild-.eb change, and putting the EAPI on
the first line, like a #!shebang.  Very easy to extract, and good design.

-Joe



Re: [gentoo-dev] GLEP 54 and hyphens in PV

2009-05-19 Thread Joe Peterson
Ulrich Mueller wrote:
 Hyphens within PV are a Bad Thing, and we should really think about
 replacing the separator for scm by something else, like a period or
 an underscore. For example, the following two would be unique:
 
 ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
 ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
 
 With our current versioning scheme the rule is very simple: ${P} is
 split into ${PN} and ${PV} at the last hyphen. This can be done in a
 straight forward way by regexp matching, and I would really hate to
 lose this nice property.

Underscore probably makes most sense, since it is similar to the
underscore used in _rc3, etc.  Of course, don't use an _ when it's
just live alone.  I agree, especially if we consider live
essentially part of the version (as  is now), and especially since
it's possible to have simply a version of live with no numeric
portion, that it should avoid the -.  Not sure I like 

-Joe



Re: [gentoo-dev] Re: GLEP 55 updated

2009-05-18 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Mon, 18 May 2009 16:07:20 +0100
 Steven J Long sl...@rathaus.eclipse.co.uk wrote:
 I missed the clamour of developers complaining about this
 oh-so-burdensome restriction that they've been dealing with for at
 least 5 years.
 
 Why do you think I wrote the awful hack that is versionator?
 Anything that finally lets us kill that off has to be good...

I have to disagree.  As Steve said, the fact that Gentoo has a strict
way to specify versions brings clarity and uniformity to our tree,
regardless of the myriad upstream conventions.  I do not think that
allowing all of those upstream conventions in our filenames is a
benefit.  It is actually quite ugly and would make the tree harder to
comprehend.  Someone looking at various packages in our tree would need
to learn each specific upstream format in order to make sense of the
filename content.  The current consistency in versions in the tree is a
great feature, IMHO.

Using versionator and $MY_PV is, as I see it, a translation method.  It
gives us the best of both worlds: the ability to deal with upstream
versions and a consistent Gentoo version format.  These mechanisms could
certainly be improved upon, of course, and handling some cases is
currently difficult, as is handing the case in which upstream's tarball
file does not contain the version, but these are fixable issues.

-Joe



Re: [gentoo-dev] GLEP 55 updated

2009-05-17 Thread Joe Peterson
Denis Dupeyron wrote:
 1. EAPI-suffixed ebuilds (obviously)
 2. EAPI in the filename with one-time extension change
 3. Easily fetchable EAPI inside the ebuild and one-time extension change
 
 My preference goes to 3 with a .eb extension and EAPI on the first line.

I second this.    :)  Although I do not have a strong preference of in-file
position, first line makes it like a she-bang, and that sounds good all around.

-Joe



Re: [gentoo-dev] GLEP 55 updated

2009-05-17 Thread Joe Peterson
Jorge Manuel B. S. Vicetto wrote:
 As others have commented, we should probably make this the last comment
 line in the header. Any suggestions for a specific identification string
 or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ?

Well, if a she-bang, should be the first line.  That also makes parsing a lot
more straightforward and easily defined.

 Looks like .eb is already taken by some exotic commercial
 application, but I think we can ignore this.
 
 I like .eb but could also live with .gebuild as was suggested before.

I'd hate to see the length grow - shrinking is better and cleaner.  :)
.gebuild is a little unwieldy IMHO.  Also, since ebuilds can be used with
distros other than gentoo itself, having the g there may not be a good idea.

-Joe



[gentoo-dev] Re: scm in GLEP 54 (was: Council meeting summary for meeting on May 14, 2009)

2009-05-17 Thread Joe Peterson
Thomas Anderson wrote:
- Vote on GLEP 54
This vote was called for by dertobi123. The vote was on whether to
approve GLEP 54 conditional on whether GLEP 55 is passed. The reason
for this is that GLEP 54 is unimplementable without the problems
mentioned in GLEP 55 being solved.

I have not seen much discussion lately regarding the choice of the string, scm
in this GLEP.  I asked the author today on IRC, and he said he doesn't have a
particularly strong reason for scm beyond historical reasons.

Since we are stuck with the string once it is adopted, I think we should
consider the choice carefully.  Personally, I'd prefer live, since it is what
we've been calling these ebuilds for a long time, it's easier to remember (and
more catchy), and it seems to carry the spirit of what we mean by these kinds
of ebuilds.  Also, there is a new in-ebuild property with the signifier live.

Comments?

-Joe



Re: [gentoo-dev] GLEP 55 updated

2009-05-17 Thread Joe Peterson
Ciaran McCreesh wrote:
 3. Extend versioning rules in an EAPI - for example, addition of the
 scm suffix - GLEP54 [1] or allowing more sensible version formats like
 1-rc1, 1-alpha etc. to match upstream more closely.
 Apart from GLEP54, I believe our versioning scheme works reasonably
 well. I don't see any need to match upstream more closely. I'd rather
 like to keep the more uniform way of handling suffixes like rc and
 alpha, that we have now.
 
 Please explain why 1.2_rc3 is legal but 1.2-rc3 is not.

I actually like the current format in that it does *not* allow - in
the version.  For example, pkg-2.3.1_rc5 makes it clear that the string
from 2 to rc5 is the version.  If were were to allow pkg-2.3.1-rc5,
this could get visually confusing (looks a bit like pkg-2.3.1-r5).  In
this case, *less* flexibility and more strict rules serve a good
purpose, I think.

-Joe



Re: [gentoo-dev] Re: The fallacies of GLEP55

2009-05-16 Thread Joe Peterson
David Leverton wrote:
 For comparson, another alternative that some people have suggested is putting 
 it in a specially formatted comment.  This avoids the issue I mentioned 
 because bash doesn't try to parse those at all, so the only rules are those 
 that specify what format the comment should be in.  On the other hand, this 
 isn't backwards compatible with current package managers.

Actually, I prefer the out-of-band approach, as well.  She-bangs are
pretty standard in Linux/Unix (for example).  But either out-of-band or
restricted in-band solutions are preferable to filename extension hacks.

-Joe



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-25 Thread Joe Peterson
Ulrich Mueller wrote:
 On Wed, 25 Feb 2009, Petteri Räty wrote:
 
 Let's try something new. I would like to get opinions from as many
 people as possible about GLEP 55 and alternatives listed here in order
 to get some idea what the general developer pool thinks.
 
 I've already commented on this in December 2007 [1], and my opinion
 hasn't changed.
 
 1) Status quo
 2) EAPI in file extension
 3) EAPI in locked down place in the ebuild
   a) new extension
   b) new subdirectory like ebuilds/
   c) .ebuild in current directory
 
 Acceptable for me would be 1) and 3c).

I have also stated my opinion before.  But I agree with Ulrich.

-Joe



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Joe Peterson
Richard Freeman wrote:
 I still don't see why we need to be encoding metadata in filenames.

Correct.  GLEP 55 tries to solve a technical implementation issue by
exposing meta data in the filename.  Extremely bad form/design, IMHO.

 PERL doesn't care what a file extension is, python doesn't care, bzip2 
 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so 
 doesn't care.  I'm sure that in at least some of these cases they end up 
 parsing parts of the file twice - once to figure out what it is, and the 
 second time to actually handle it.  I'm actually hard pressed to think 
 of any unix-based software that uses the filename to store a mandatory 
 file format versioning specifier of some kind.

All good points.  I cannot believe there exists no other way to solve
this technical issue other than resorting to such a non-Unix-like idea.
Obviously all of the software packages cited above endeavor to avoid
such nastiness.

I do not understand why anyone is willing to accept putting version info
in the filename/extension.  It is inelegant and, frankly, very ugly.  I
have written more in the past on why I think it is a terrible idea, so I
won't repeat it here.

Suffice to say, if something like GLEP 55 is implemented, I will lose a
lot of faith in Gentoo's design, so much so that I will likely join the
ranks of those who abandon it, not only as a dev, but also as a user.

 This seems to me to be a solved problem.  You put a header in a file 
 that tells you how to read the file.  Headers are split into fields and 
 if a program doesn't know what to do with a field it ignores it (or if 
 the header so instructs it doesn't even try to parse the file).  This 
 should be easy to do and keep the file bash-compatible.  Just stick a 
 comment line close to the top of the file and put whatever you want on 
 it.  You could also stick something in metadata.xml (although this makes 
 working with ebuilds outside of a repository more difficult).  You run 
 the file through an algorithm to find out what the EAPI is, and then 
 source it if appropriate.
 
 Sure, if you make some major change analogous to switching from the .rpm 
 to the .deb package format then maybe an extension change would make 
 sense.  But, why expose the inner workings of the package file format to 
 the filesystem?

+100

-Joe



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Joe Peterson
Richard Freeman wrote:
 The dynamic linker doesn't need to consult the filename to figure out 
 how to parse a shared object.  It only consults the filename to figure 
 out which shared object is needed.  That is actually analogous to 
 putting the package name/version in the ebuild filename.

Right.  Plus, if the linker *did* consult the filename, imagine what
would happen if someone renamed the file (even by accident) and changed
the version?  The parser should not be able to be so easily fooled -
could cause great confusion and or nasty and weird bugs - seems very
fragile to me.  Having the version *in* the file is much safer, since
monkeying with that would require editing it the file, rather than
renaming it.

-Joe



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 09:24:48 -0700
 Joe Peterson lava...@gentoo.org wrote:
 Right.  Plus, if the linker *did* consult the filename, imagine what
 would happen if someone renamed the file (even by accident) and
 changed the version?  The parser should not be able to be so easily
 fooled - could cause great confusion and or nasty and weird bugs -
 seems very fragile to me.  Having the version *in* the file is much
 safer, since monkeying with that would require editing it the file,
 rather than renaming it.
 
 You could use the same absurd argument to say that PN and PV shouldn't
 be in the filename...

No...!

They are needed because:

1) versions of the *content*, not the *format* are needed for uniqueness
2) it makes sense to have these in the filename, but not internal meta-data



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-12-15 Thread Joe Peterson
Donnie Berkholz wrote:
 On 15:35 Mon 01 Dec , Joe Peterson wrote:
 However, what I see as perhaps a missing piece is more conceptual: the
 important connection between the valuable info in the emerge logs (and their
 somewhat transient default nature) and what a user looks for when he/she has 
 a
 problem with a package.  Yes, users will realize this as they use Gentoo (and
 will start paying more attention to logs as a result), so I don't think it's 
 a
 huge problem, but what this particular user said to me made me think that
 there is, perhaps, an opportunity to improve the situation.
 
 Based on the rarity of me seeing this reported as a problem, I'm 
 inclined to think it says more about this user than about our system.

This could very-well be.  However:

 I don't think it's our responsibility to put documentation everywhere 
 someone might conceivably look for information.

I agree with this statement, but I wasn't implying we should duplicate
information everywhere.  I wanted to explore this as an opportunity to
re-think if having an official de facto spot for gentoo readmes
would make sense, thereby saving log output in a useful place where
users would learn to look regularly.  I agree this would only be
reasonable if it were the right thing, architecturally, for Gentoo, not
just for this one user's issue.

-Joe



Re: [gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS

2008-12-04 Thread Joe Peterson
Diego 'Flameeyes' Pettenò wrote:
 Alec Warner [EMAIL PROTECTED] writes:
 
 Looks Good To Me, but I would prefix the JOBS variable with some sort
 of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other
 systems that may use JOBS internally already (seems vaguely likely).
 
 Good point, GENTOO_JOBS sounds good to me.

How about PORTAGE_JOBS to go along with PORTAGE_OVERLAY,
PORTAGE_NICENESS, etc.

-Joe



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-12-01 Thread Joe Peterson
Gilles Dartiguelongue wrote:
 As others have said, there are already proper systems, documentation and
 linking through other docs. Not finding this is what I'd call lazyness
 or lack of google foo. Don't misunderstand me, some stuff can get ouf of
 the radar of everyone, it's ok, real people are still here to point you
 in the right direction.

I think that I probably did not express my idea as well as I could have, since
most of the responses I have gotten have echoed your thoughts that Gentoo
does, indeed, have the facilities to achieve flexibility in logging, etc.

I totally agree.  Gentoo's capabilities, although not perfect, of course, are
superlative and are a complement to its superb online doc.  I think that's a
big reason why we're all here - we see this and appreciate this.  In fact,
even when I do not include the word gentoo in a Google search, I more often
than not end up at a Gentoo doc page - this is impressive.

However, what I see as perhaps a missing piece is more conceptual: the
important connection between the valuable info in the emerge logs (and their
somewhat transient default nature) and what a user looks for when he/she has a
problem with a package.  Yes, users will realize this as they use Gentoo (and
will start paying more attention to logs as a result), so I don't think it's a
huge problem, but what this particular user said to me made me think that
there is, perhaps, an opportunity to improve the situation.

There is no Gentoo-specific readme facility, which could be the obvious and
de facto place to go when trouble is had.  I can imagine that a fairly simple
and low-effort way of starting such a resource would be to simple echo the log
output into a package-specific file in a known place (or put it in the portage
db).  The logging facilities allow similar things if configured to do it, but
it is not on by default.  Once users know where to go to see the
instructions or notes on getting a package up and running after
installation, this would become a good place to have such info or to expand on
how the facility works.  Starting with just the plain emerge log output would
be an easy way to get benefit of such a concept has merit.  And by no means
would such a thing be an attempt to replace the excellent on-line docs or
wiki, either - I see both as having unique strengths.  For example, for
detailed info on packages, the wiki/web stuff is the better resource.  For a
quick check of whether a revdep-rebuild might have been necessary after
installing a new package would typically be in the log/notes.  The notes also
have the key advantage that they would *always* contain what the log output
was, whereas whether a wiki or web page exists on a particular package depends
on whether someone spent the time to author one.

My intention with the RFC was to see if the concept has any worth and to kick
it around a bit.  I do not really see this as a deficiency in Gentoo's
technology (which I have a feeling is how many here have interpreted it), but
simply something that, if done correctly, could be useful.

-Joe



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Joe Peterson
Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?

For that matter, whatever is decided, why not include DESCRIPTION?
This seems to me a candidate for something that does not change version
to version (or at least shouldn't - since there is only one displayed,
e.g., in emerge --search).

-Joe



[gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Joe Peterson
I recently had a user write to me after banging his head against the
wall for a while, trying to get a package working.  By the time he wrote
me, he had already figured it out, but he wanted to convey to me that
what finally helped was actually the emerge output (which stated exactly
how to get things working - in this case, the need to run emerge
--config).  He had not noticed this before and only saw it upon
re-installing, given the transient nature of the emerge messages.

Bottom line here is that there is extremely valuable and critical info
in our emerge output.  In a way, these messages are like Gentoo-specific
READMEs (or release notes and/or install instructions).  However, it is
not saved for a user to use as a resource later (well, except that it is
partially saved in the master emerge.log, but that's not quite useful
enough).  There is no official place to go to look for Gentoo
instructions; /usr/share/doc is one logical place, but it only contains
files actually installed, not the notes output by emerge (and these are
usually upstream-supplied, not Gentoo).

I propose that, upon merging a package, we save the emerge messages in
either: 1) a package-specific file that resides somewhere official or
2) in the portage DB, so that the messages can be re-read via a portage
utility.  In the latter case, either a new option to equery or a new
q command (e.g. equery readme pkg or qreadme pkg could
retrieve the text).

In either case, there would then be a place to go that is known and
consistent (and can be documented in the Gentoo doc).  It could, in
essense, serve as a kind of Gentoo package README collection.  I could
also imagine later expanding on this by letting a given package also
include more thorough README info from a file if the maintainer so desires.

-Joe



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Joe Peterson
Marius Mauch wrote:
 By default, messages generated by elog, ewarn and eerror are recorded
 in /var/log/portage/elog/summary.log (emerge.log is just a
 transaction log, so best to ignore it here). einfo isn't recorded on
 purpose as it isn't intended for important information (that's the
 purpose of elog). There are some tools available to simplify reading
 these messages, and there several additional/alternative delivery
 modules available (by mail, IM or in package specific files),
 customizable via POTAGE_ELOG_* variables. Don't know if you just
 haven't been aware of this, or if you're asking for something
 completely different.

I'm really proposing something different - in essence, the above is to
obscure to really serve as a good official kind of readme source for
users.  There needs to be something simple and straightforward (and
well-documented) as the official thing to look at if one is having
trouble with a package.  In the case I mentioned all it took was for
that user to see the messages, but it did not occur to him that the info
would be there.  I could even imagine that einfo should be included in
what I am suggesting, since it may not be important for logging, but
might be nice to have, nonetheless.

-Joe



Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-11-30 Thread Joe Peterson
Peter Volkov wrote:
 Seems that we already have everything you dreamed about: 
 
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=1#doc_chap4
 
 Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
 mail :)

This is all cool, indeed!  :)

I suspect, however, that most users have never played with these
variables.  I think that saving this info in the portage db or making it
more default/official in some way could be a great help.  The core
problem is, I think, that many users do not know where to look when
having trouble, so they may not even realize that what they need is in
the log info.

The reason I was phrasing it more in readme terms is that most people
can identify with that concept, and it could be made clear that there
exists Gentoo-specific readme info that is always available (regardless
of whether a user sets up the portage logging stuff).  The bare log
messages could exist as a minimal default for packages that do nothing
special to provide more readme info.

-Joe



Re: [gentoo-dev] An official Gentoo wiki

2008-11-12 Thread Joe Peterson
Josh Saddler wrote:
 It takes time and effort to produce one of our polished, professional
 documents. That's duplicating the time and effort that it takes to write
 a decent wiki article -- pointless duplication.
 
 One of the things I'm hearing from just about every other user and
 developer is that users would be providing the peer review necessary to
 keep documents at a general level of quality. This means let the wiki
 live its wiki life, which means there's no need to reformat the article
 as something else. If it's a decent wiki article, then it should stand
 on its own meritsas a wiki article, nothing else. It's a community
 contributed article on the community-contributed resource. That's where
 it belongs.
 
 Most folks have said they're okay with official Gentoo documentation and
 a second community-contributed resource (that may not be as accurate,
 tested, readable, etc.) So keep that system around. If you want to jot
 up a quick howto, or an article filled with individual speculation and
 anecdotes, keep it on the wiki. If you want a doc to be considered *the*
 authority on its subject (such as
 http://www.gentoo.org/doc/en/xfce-config.xml ;)), maintained by Gentoo
 developers, then submit it to the GDP via bugzilla, or provide updates
 to one of the docs we already have.
 
 There really is no reason why we can't have this split. There's no need
 to XMLify every halfway decent wiki article just because it's so much
 better than everything else on the wiki. Trying to do so involves an
 inordinate number of work hours and staff that we just don't have, not
 to mention greatly raising the existing maintainer burden.

++  Good plan.

-Joe




Re: [gentoo-dev] An official Gentoo wiki

2008-11-11 Thread Joe Peterson
Mark Loeser wrote:
 What are others feelings on this?  What issues do you see with having a
 wiki?  Do you see anyway to resolve the issue you see with us having a
 wiki?

+1!  I have set up several wikis for work projects and used many others
to great benefit.  Even those (on my work projects) who were skeptical
at first warmed to the idea and quickly became dependent on such tools.

As for Wikipedia, there is always the fear that the info will be
incorrect, but time has shown that wikis tend to be very accurate and
get corrected quickly when not.

-Joe



Re: [gentoo-dev] Reinstating eclasses

2008-11-04 Thread Joe Peterson
Petteri Räty wrote:
 The names of eclasses aren't shown to users and I think figuring out a
 new name is a minor inconvenience so I would just go with the safe route.

I disagree: we should use care in choosing names, since these names will be
around for a long time.  Using an ugly name might not be visible to the users
so much, but we, as devs, need to see them, and we might as well be elegant
where possible.

-Joe



Re: [gentoo-dev] Reinstating eclasses

2008-11-04 Thread Joe Peterson
Christoph Mende wrote:
 Now the most logical name for an eclass like that
 would be xfce4.eclass, except that eclass already exists.

Since the new eclass is not version specific, how about simply xfce.eclass?

-Joe



Re: [gentoo-dev] Re: Reinstating eclasses

2008-11-04 Thread Joe Peterson
Ryan Hill wrote:
 On Tue, 04 Nov 2008 13:43:55 -0500
 Joe Peterson [EMAIL PROTECTED] wrote:
 
 Christoph Mende wrote:
 Now the most logical name for an eclass like that
 would be xfce4.eclass, except that eclass already exists.
 Since the new eclass is not version specific, how about simply
 xfce.eclass?
 
 why bother introducing yet another xfce*.eclass when you can re-use an
 existing one?

Well, my thought (without knowing xfce details, albeit) if the eclass is now
not tied to version, having one with no version info in the name might serve
future xfce versions (5, 6, 7...) as well without requiring yet another name
change.

-Joe



Re: [gentoo-dev] Re: Reinstating eclasses

2008-11-04 Thread Joe Peterson
Christoph Mende wrote:
 Well, the desktop is usually called Xfce4, plus that'd match gnome2...
 and more or less kde4

In general, it makes sense to me to have an unversioned one if there is no
version dependency - i.e. if xfce.eclass would likely work for future ones
(like xfce5).  I'm not sure why, other than to emphasize that a new version
is out, upstream packages (like gnome, kde, etc.) include the version in the
name.  I actually just think of kde as kde, myself, even if it happens to be
version 4.  ;)

-Joe



Re: [gentoo-dev] kerberos USE flag

2008-10-31 Thread Joe Peterson
Michael Hammer wrote:
 * Doug Goldstein [EMAIL PROTECTED] [081031 15:53]:
 If no one opposes, I say we redact this USE flag asap.
 
 ++

I was also wondering why kerberos was on by default - I definitely
approve of nuking it.

-Joe



[gentoo-dev] Last rites: media-plugins/slimserver-alienbbc

2008-09-23 Thread Joe Peterson
# Joe Peterson [EMAIL PROTECTED] (23 Sep 2008)
# Masked for removal in 30 days (see bug #238442)
# Depends on old media-sound/slimserver
# Will bring back in a form that works with media-sound/squeezecenter
media-plugins/slimserver-alienbbc



[gentoo-dev] Last rites: media-sound/slimserver

2008-09-22 Thread Joe Peterson
# Joe Peterson [EMAIL PROTECTED] (22 Sep 2008)
# Masked for removal in 30 days (see bug #238442)
# Replaced by package: media-sound/squeezecenter
media-sound/slimserver

-Joe



Re: [gentoo-dev] Bug wrangling

2008-09-08 Thread Joe Peterson
Christian Faulhammer wrote:
 everyone working on bugs, please add all people from metadata.xml to
 the assignee or cc field, I regularly have to search for bugs where a
 team and I maintain a package because only the team has been added.
  Second, please use full atoms (cat-egory/package) in the Summary
 field, so searching is easier.

Sorry if this answer can be found elsewhere, but if one has a proxy maintainer
(i.e. not a Gentoo dev) for a package, can/should this person be added to
metadata.xml?  Is there a special tag for this?  I can certainly see this
being helpful (so that person automatically gets on the cc list at least).

Thanks, Joe



Re: [gentoo-dev] Bug wrangling

2008-09-08 Thread Joe Peterson
Jeroen Roovers wrote:
 Sorry if this answer can be found elsewhere, but if one has a proxy
 maintainer (i.e. not a Gentoo dev) for a package, can/should this
 person be added to metadata.xml?  Is there a special tag for this?  I
 can certainly see this being helpful (so that person automatically
 gets on the cc list at least).
 
 metadata.xml should explain precisely whom to assign/CC to. The normal
 maintainer tag should be used to list proxy maintainers just like it
 lists Gentoo developers, and the email tag for a proxy maintainer
 should list an e-mail address that bugs.gentoo.org knows about.

Thanks to all who replied!

-Joe



Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

2008-09-05 Thread Joe Peterson
Marius Mauch wrote:
 If it's only used to indicate that the package doesn't install any
 files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual'
 somehow implies that it's only applicable to packages in the 'virtual'
 category, which isn't the case with the given definition (as you said).

I like virtual, since it really gets at the spirit of what the ebuild does.
empty sounds like it does nothing at all, and nocontents sounds that way to,
to me.

An analogy to virtual is a virtual method in OO programming - it sits at a
high level, does nothing in itself, but causes underlying methods to perform the
work.

-Joe



Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

2008-09-05 Thread Joe Peterson
Marius Mauch wrote:
 Not sure if 'live' is really the best choice here, as many things also
 apply to e.g. automated daily/nightly snapshots/builds that might also
 be useful to support. Maybe 'unversioned' is more accurate.

I think the most important thing to convey with this property is that the source
code can change at any time, since it is pulled live from upstream.
unversioned doesn't really imply this - it makes it sound like it simply has
no version.  Maybe something akin to volatile would work, but I still like
live, personally.

-Joe



Re: [gentoo-dev] News item: World file handling changes in Portage-2.2

2008-09-05 Thread Joe Peterson
Marius Mauch wrote:
 First, regarding the news item, I'd suggest that instead of telling
 users to modify world_sets manually to use `emerge --noreplace @system`.

++

 Second for the suggestions on how to handle the transition:
 - treating 'world' and '@world' differently is a no go from my POV. One
 of the main reasons to implement them as sets was to remove special
 case code in emerge, so I'm quite opposed to adding new special cases
 instead. And I'm quite sure that such a separation would cause
 confusion, and some isues regarding (end-user) documentation.

+++

-Joe



Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

2008-09-05 Thread Joe Peterson
Ciaran McCreesh wrote:
 Except it doesn't. A virtual ebuild:
 
 * installs nothing
 * does nothing

I'd say that virtual does indeed do something: it pulls in other packages.

 * should be treated as being very quickly installable
 * should be treated as having zero cost for installs
 
 The property proposed corresponds to only the last of these.

Still, the term virtual fits the spirit of the idea well.

 Virtual methods in OO can do lots. You're thinking 'pure virtual' or
 'abstract'.

Yes, you are correct (pure virtual is what I was thinking).

-Joe



Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

2008-08-31 Thread Joe Peterson
Ciaran McCreesh wrote:
 Users don't need to see it.

I cannot quite agree on that point.  Given that Gentoo is a distro that
appeals to the more technically-oriented users, I personally believe
that what we expose as ebuild syntax is actually exposed to many users
fairly profoundly.

-Joe



Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

2008-08-25 Thread Joe Peterson
Zac Medico wrote:
 Then change the name. Call it zero-install-cost.
 
 I'm inclined toward virtual since it's more brief and I think it
 might strike a chord with more people because of their familiarity
 with the virtual category and old-style PROVIDE virtuals. We'll
 have to see what others have to say.

Zac, absolutely.  ++

-Joe



Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

2008-08-23 Thread Joe Peterson
Zac Medico wrote:
 Do the name and definition of this PROPERTIES=live value seem good?
 Would anybody like to discuss any changes to the name, definition,
 or both?

++

-Joe



Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2

2008-08-19 Thread Joe Peterson
Duncan wrote:
 That's an interesting idea.  I don't personally care either way, as long 
 as @world continues to /not/ include system/@system, but having world 
 (without the @) continue to include system /would/ be useful for backward 
 compatibility.  I think it'd be much better in terms of ease of educating 
 the vast majority of stable users, as the @ is new anyway, so it can have 
 new behaviour without a problem, but having new behaviour for world does 
 present a significant re-education/retraining issue.

The only drawback I see is that we would then have the following:

@system == system
...but...
@world != world

This, I would think, could cause confusion too - and we'd have to live
with and document this quirk.

How about issuing a warning when portage starts if the user specifies
world (with no @ sign) as the only specified target *and* @system is
not in world_sets?

It would warn that the world set no longer automatically includes system
 (i.e., @system) and also that it is better, from now on, to explicitly
use the @ sign for all sets like world and system (since these two are
special cases grandfathered in).

-Joe



Re: [gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2

2008-08-19 Thread Joe Peterson
Steve Long wrote:
 @system == system
 ...but...
 @world != world

 This, I would think, could cause confusion too - and we'd have to live
 with and document this quirk.

 I don't see that as major from a user pov; as soon as you see @ you're in
 set territory, which is for finer-grained control. We already expect users
 to have the ability to read docs and the like, and this way we're not
 introducing any surprises; for the standard update procedure we're all used
 to, sets don't come into it.

Ah, OK.  I have been considering that world is simply a grandfathered name for
@world (and same for system).  I.e. that world is also specifying the world
set, but that only world and system are allowed to have the @ dropped to avoid
breaking things for users.  Isn't that the way the code treats it now?

Or is world (no @) really not a set?

 How about issuing a warning when portage starts if the user specifies
 world (with no @ sign) as the only specified target *and* @system is
 not in world_sets?

 It's starting to get tricky.. ;)

It just seems like that's the most common case (expecting world to include
@system and @world), so if it doesn't, warn the user, and in the process
migrate users to using @ (to avoid the warning).

 .. and we still get the issue that future usage would mean needing: 
 emerge @world @system # or should it be the other way round?

True, but as Duncan discovered, if you leave off the -1, @system gets put in
world_sets anyway, and some might want that.  Then @world includes both.

 ..when we used to have a simple 'emerge world'[1]. I don't see how that
 helps our users. iow the change feels like a loss, not an improvement
 (which the set code certainly is), when a little tweaking with the option
 parser would mean we had both uses. I see it as polishing the UI, nothing
 more.

I know what you mean.  And I'm not sure what makes most sense.  It still seems
potentially confusing for world and @world to mean different things.  If the
words were different, it would not seem that way.

 Maybe there's a case for dropping system as a special-case over time, and
 giving a deprecation warning.

Yeah, I'd vote for that.

-Joe



Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.

2008-08-18 Thread Joe Peterson
Jeremy Olexa wrote:
 Also, devs willing to maintain
 packages but then later retiring and leaving the packages in limbo.
 Maybe there should be some policy such as, when devs retire if no one
 else steps up to maintain the package, then it automatically gets
 moved to sunrise overlay and only maintained packages stay in the
 portage tree.

My opinion is that packages should not be removed from the tree just because
there is no assigned maintainer.  Even moving a package to sunrise effectively
makes it invisible to many users, and a great strength of Gentoo is that it
has such a variety of packages in the tree.

I do see that there are potential problems with unmaintained packages, so it
is a good goal to try to solve that.  Perhaps developers who have the time and
choose to make themselves available to do simple version bumps on unmaintained
packages could put themselves on a mailing list to receive such bug reports.
Encouraging users to be proxy maintainers is a great idea too (as others have
suggested).  As a last resort, otherwise working packages could be masked as
unmaintained, which is probably better than total removal (after all, they
could still be useful to some users.

-Joe



Re: [gentoo-dev] [RFC] Should we introduce PROPERTIES into the ebuild metadata cache on the rsync mirrors?

2008-08-13 Thread Joe Peterson
Zac Medico wrote:
 Please consider the introduction of a new PROPERTIES variable to
 the ebuild metadata cache that's distributed via the rsync mirrors
 and resides locally in the ${PORTDIR}/metadata/cache/ directory.
 This variable is intended to have identical syntax to the existing
 RESTRICT variable, including support for the USE conditional syntax
 that is also supported by the LICENSE, PROVIDE, SRC_URI, and *DEPEND
 variables.
...

++ (and I don't see a problem with adding it at this time).

-Joe



Re: [gentoo-dev] [RFC] New PROPERTIES=live-sources setting for ebuilds?

2008-08-06 Thread Joe Peterson
Zac Medico wrote:
 To simplify things, how about if we just do a
 PROPERTIES=live-src-unpack for now, to indicate exclusive access to
 $DISTDIR during src_unpack? Thats a simple and portable baseline
 that will be quite useful even without anything finer grained.

No need for a convoluted and long name like 'live-src-unpack'.  Why not
keep things simple (how about just 'live'?).  You are trying to say it's
a 'live' ebuild (i.e. it gets the sources from a live source) - that's
all.  The locking issues are a technical detail, and there's no need to
spell out all aspects of the property in the name; it's just confusing.
 In fact, you may want to change technical implementation details later,
and it would be best not to have left-over details in the name that then
would not apply.

-Joe



Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

2008-08-03 Thread Joe Peterson
Vaeth wrote:
 The main point in introducing the live USE flag should be IMHO to
 let the user decide whether the sources should be fetched. The fact
 that IUSE then marks live ebuilds in the way which you wanted is an
 additional side effect.

A tend to agree with Zac that USE flags should not dictate package
manager behavior (e.g. whether a package gets included in a specific
package set or defining a package as live), and the idea of the IUSE
side-effect seems a bit unclean (i.e., behaviors that the dev did not
intend might end up being a surprize; I think we need to be careful
about side-effects).

However, I do see the point about the RESTRICT variable.  Throwing
random flags into it does not seem ideal, and I think convenience should
take a back seat to correctness when designing, e.g., ebuild
syntax/rules.  But why would using a new variable require an EAPI change
any more than adding new flags to RESTRICT?  I.e., if people start using
OPTIONS= or FLAGS=, it would simply be ignored by older package
manager versions, just like new RESTRICT values would be ignored.  Or am
I missing something fundamental?

-Joe



Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

2008-08-03 Thread Joe Peterson
Zac Medico wrote:
 What you're missing is that only a specific subset of variables is
 cached in /usr/portage/metadata/cache. Now that you mention it, we
 could introduce a new variable called EBUILD_FLAGS and start caching
 it in new versions of portage. It wouldn't necessarily require an
 EAPI bump as long as it can safely be ignored by older versions of
 portage.

Yes, that was my thinking.

 Oh and by the way, I should mention that it might not be worth it to
 add a whole new variable. I think RESTRICT=live-sources is a
 perfectly fine, especially considering the the existing
 RESTRICT=primaryuri value is similar in some ways, including
 perceived polarity. If we do decide to add a new variable then
 perhaps we should move primaryuri to the new variable as well, for
 consistency.

Yes, that's sort of what I am thinking.  Migrate options that really do
not belong in RESTRICT to another variable (and keep them in RESTRICT,
of course, for backward compat for now).  Then introduce new ones into
whichever variable makes sense.

I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary
(redundant?).  Maybe even OPTIONS or PROPERTIES makes more sense.
In fact, FLAGS might be a little too generic, even?  Worth a short
discussion.

-Joe



Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

2008-08-03 Thread Joe Peterson
Zac Medico wrote:
 Personally I think people are far too concerned about the name of
 the variable. I only see a what I consider to be a trivial or
 negligible benefit in separating these things into two different
 variables. However, it it makes more people happy then I guess I'm
 for it.

Different people have differing sensitivity to things like this
(aesthetics, consistency, etc.).  IMHO, this particular one is not a
*huge* deal (picking my battles, I personally would not choose to be too
vehement on this one), but it's always nice to pick the most
elegant/logical way to do things, especially for things that are exposed
to the dev/ebuild interface and are hard to change later.

-Joe




Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-20 Thread Joe Peterson
Peter Volkov wrote:
 This means that every ebuild which uses 'unpack ${A}' should have in
 DEPEND a program which is selected by filename extension of sources. So
 as I understood your initial suggestion was to make this happen
 automatically. And this is very logical as makes ebuilds cleaner and
 more terse. So why did you changed your mind and try to write another
 eclass (which then should sit in the tree forever), to create duplicate
 unpack function instead of just making step you suggested initially? Is
 there any intension to remove unpack logic from package manager? And if
 yes, why?

++

I also was wondering this.  And if we add unpack2(), which could be a
little hard to explain in the documentation, it will need to be there at
least until ebuilds stop using it (when portage gets this functionality
ultimately).

For my uses, I'd rather do deps manually and use the official portage
unpack() until portage has such features in order to keep my ebuilds
looking a bit more clean.

-Joe




Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-17 Thread Joe Peterson
Marius Mauch wrote:
 The eclass also contains it's own implementation of unpack (renamed to
 unpack2) and src_unpack so the logic which tools/packages are used for
 unpacking can be maintained in a single place instead of being
 splitted between the package manager and the tree.

Marius, these look like nice functions.  A couple of questions:

1) Since it requires altering an ebuild to use these features (i.e. no
automatic), what is the advantage over just including the dep the usual way?

2) The name unpack2 is intended to be temporary, right?  ;)  I'd guess that
after this functionality is integrated into portage, there would be no need
for the extra unpack func.  But then we'd probably have to keep unpack2 for
a long time as an alias.  Any way to avoid that?

3) Same would go for the needed call for unpack_update_depend, correct?  I.e.
it would not be needed after portage has this functionality (and at that
point, the unpack and dep code would be unified cleanly).  So this function
would then become a stub, correct?  The only thing here is that ebuilds could
linger for some time without being cleaned up.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Council meeting summary for 10 July 2008

2008-07-15 Thread Joe Peterson
Petteri Räty wrote:
 I am saying that it makes sense to approve both at the same time or have 
 other official package managers approved before accepting the GLEP.

In addition, I'd want to see why the particular approach suggested in this
GELP is the only way (as some seem to claim).  I have yet to be convinced of
this, and as I've pointed out before (and do not wish to belabor further
here), I believe there are major drawbacks to putting the EAPI in the
filename/extension.  Rushing to approve this GLEP would be a mistake, IMHO.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] sci-libs/scipy - dev-python/scipy ?

2008-07-08 Thread Joe Peterson
Marijn Schouten (hkBst) wrote:
 I suppose you mean git. Since it tracks content and not files, moves are
 trivial. Git actually finds your moves for you, after you've moved content
 around; such as when doing a bump.

Even better!

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] sci-libs/scipy - dev-python/scipy ?

2008-07-07 Thread Joe Peterson
Donnie Berkholz wrote:
 I actually object to having crap in dev-python, because things should be 
 categorized functionally instead of by the language they're implemented 
 in. 90% of the time you don't care about the language. But category 
 moves are pretty much pointless, so I don't normally bring it up.

Do you mean it is pointless because categories are pointless, or because
it is not worth the trouble of doing the move?  I assume we inherited
the category idea from fbsd ports.

Since we have categories (and assuming we'll keep them), I think that
things should be categorized as correctly as possible (perhaps it's not
the highest priority, but better to have it right than not, eventually).

If it is better to have scipy in sci-libs rather dev-python, then
perhaps other dev-python packages (like you said) should be moved
elsewhere to be consistent.  A quick look at the fbsd ports shows that
scipy is in science and numpy is in math (for example), so that
agrees with your feeling that neither belong in dev-python.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] sci-libs/scipy - dev-python/scipy ?

2008-07-07 Thread Joe Peterson
Donnie Berkholz wrote:
 I meant moves were largely pointless, although categories are to a 
 lesser extent. Tags would be a lot better, since nothing can be 
 categorized perfectly into a single place.

Yes, I can see the benefit of a tag paradigm.  I, myself, find it more
trouble than benefit to have the extra directory level.  I often do cd
/usr/portage/*/foo to get to the foo package, and it often gets a hit
in licenses or elsewhere that trips up this practice...

 I don't think it's worth losing track of the CVS history just so we can 
 have something in a different place that ultimately is hardly useful to 
 anyone.

Ah yes, CVS would present a problem here.  I suppose if/when the whole
tree is converted to svn, at that point moves would be more practical.
Too bad, though, that this has become a barrier to the ability to change
a category easily and without losing the history.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: 0-day bump requests

2008-07-03 Thread Joe Peterson
Tony Chainsaw Vroon wrote:
 The time I can spend
 trawling upstream sites for new releases is limited.

Same here - I would never mind getting a 0-day bump request, since
someone else might have noticed before I did that a new version is
available.

 Just an idea:
 How about a metadata.xml tag that indicates whether early bump requests are 
 welcome?
 It's more of an individual developer preference, but that seems the right 
 place for it.

It might make sense if the default were that 0-day is OK (especially if
most devs don't mind).  If not, then the tag could specifiy the number
of days to wait...

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-16 Thread Joe Peterson
Duncan wrote:
 Jim Ramsay [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Mon, 16
 Jun 2008 08:34:01 -0400:

 Well, this is true and it isn't... In the case of:

   ewarn line one
   eblank
   ewarn line two

 Obviously it would be the same as ewarn.  However, what about here:

   ewarn line one
   eblank
   elog line two
   eblank
   einfo line three

Yes, this is a tricky case.  In the case where the previous and next
output lines differ like this, a grey * could be used, or perhaps a
green one.  However, read more below on my response to Duncan.

 Here's a novel idea, let blank lines be /real/ blank lines! =8^)

Duncan, your point is well-taken.  Taking that idea one step further,
how about using a neutral color for the * when eblank is used.
For example, a medium grey.  This would avoid needing logic to guess the
correct color, and it would nicely integrate with the rest of the visual
flow/look of the output.  Although I was originally imagining a
context-based color picker, this may be, indeed (as some have pointed
out) overkill.

The actual issue has mostly to do with conditionals like in the example
I gave a while back (in which the blank lines need to be within the
conditionals to avoid bunching up of blank lines when the conditionals
are false).  Currently, I tend to color the * the same as the
preceding lines (I have no choice bu to pick some color), but this
doesn't really look right, depending on how the conditionals play out.

I am leaning more and more toward the idea of a neutral color for
eblanks, as this would indeed be trivial to code and it would make
output make more sense, especially for conditionals, but for other cases
as well.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-15 Thread Joe Peterson
Benedikt Morbach wrote:
 On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov [EMAIL PROTECTED] wrote:
 But speaking about names of options - -A and -B are easier to remember
 as -A stands for above and -B for below and grep users already knew
 that.
 
 for grep -A means after and -B before ;)

I (not having used those grep options frequently), would find it hard to
remember if -A meant blank line after this or this after a blank
line.  I am more visual person, so I'd find the separate
eblank/eseparator easier to visualize, and the look of the ebuild src
would match the output more naturally.

As for why it would be more useful than eerror/ewarn without an
argument: it would potentially allow for intelligent context-based
coloring of the * (based on surrounding lines).

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: A few questions to our nominees

2008-06-14 Thread Joe Peterson
Ryan Hill wrote:
 (...I would change the suffix to -live, just because i
 hate the term SCM :P)

++ on using live and not the scm acronym (no matter which idea is
selected), especially since there are various different acronyms for
config mgmt (scm, cm...), and scm's meaning is less obvious at first glance.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55 (why use filename extension?)

2008-06-11 Thread Joe Peterson
Peter Volkov wrote:
 Well for me .ebuild-eapi is much more confusing.
 
 I still don't see why it's impossible to have eapi as a part of name but
 not in extension...

Although putting EAPI in the name and not the extension is *slightly*
preferable to using the extension, I still do not think that it even
belongs there for one main design-based reason:

It does not have to be there from a design perspective.

All other filename components (name-version-revision.ebuild) uniquely
identify the ebuild.  EAPI does not (it is meta-information only needed
internally by the package manager or by someone interpretting the
contents of the file).  You could not have two ebuilds, for example,
that have identical name/version/revision but different EAPIs - that
would not make sense (and yet it would be possible if the EAPI were in
the filename, causing the package manager to need rules for choosing the
right ebuild to look at).

The argument for putting the EAPI in the extension or filename is simply
to address a particular technical implementation detail, and there are
other, better, ways to solve the problem in my opinion.

I would argue that GLEP 54 is also putting needless extra stuff in the
filename, but we won't go there right now.  :)

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Mon, 9 Jun 2008 22:35:25 -0700
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 Did anyone already propose specifying this in metadata.xml?
 
 Yup. That's a no-go, since metadata.xml is quite rightly treated as
 being not suitable for anything the package manager really needs.

I think a separate file, especially one that uses a standard XML format,
would be a fine place for things that the PM needs.  Just because we do
not use it this way now does not mean it is not a good idea.  Also, the
EAPI would be out-of-band and not require sourcing of the bash script to
determine.

 It also moves the EAPI definition even further away from the ebuild,
 which makes it even harder to work with.

Harder to work with in what way?

 And, of course, it's not backwards compatible, so it'd still need a
 file extension change.

I am not convinced of this.  As others have stated, portage/PM should be
upgraded with the new capability well in advance of new EAPIs.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Rémi Cardona wrote:
 Ciaran McCreesh a écrit :
 picard_facepalm.jpg
 
 I don't think any of us are completely thrilled by either proposals, but 
 the EAPI-in-a-separate-file does have the potential for more 
 flexibility, ie package-wide EAPI.
 
 And it does keep filenames simple enough.

+1

-Joe


-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Luca Barbato wrote:
 Check if exists a line EAPI=*$, if does and the rest of the string 
 matches an understood eapi, go on sourcing, otherwise ignore/mask it...

And placing it out-of-band (like # EAPI=...) avoids any sourcing
errors, makes parsing faster, etc.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55

2008-06-10 Thread Joe Peterson
Jan Kundrát wrote:
 If the user knows that keywords are set by the KEYWORDS variable, then
 she must be familiar with the EAPI. The meaning of the KEYWORDS variable
 is defined by the EAPI.

But that's not really what I find objectionable.  There's no need to
make EAPI so special that it alters the file extension.  If EAPI is
accessible as part of the file or in metadata.xml, e.g., it still serves
this purpose well, and that info is exposed at the right level.

 Sure. If current EAPI specified that a sequence of four bytes starting
 at offset  0x10 is a little-endian magic number that is used to identify
 an EAPI, that'd be all we want. However, current format definition is
 rather complex; there's nothing as simple as read several bytes at some
 offset and use them.

I would not suggest byte-level methods, no - these files are not binary.
 There are simple ways to parse text files to find the EAPI.  If it is
in the ebuild, putting it in the header (out-of-band) works.  If it is
in metadata, simply parsing XML works.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Rémi Cardona wrote:
 Ciaran McCreesh a écrit :
 Kills the upgrade path completely. No good.
 
 Lemme sum this up in layman's terms :
 
 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
 avoid that for various reasons, all 100% valid.
 
 2) Putting the EAPI in the filename :
 
   + it solves 1)
   + it keeps backward compatibility because old PM won't recognize the 
 filenames
   - it's not very pretty

I'd say the problems go way beyond just being not pretty.  That longish
email I wrote yesterday has a bunch of reasons I don't like it.  And
pretty makes the issue sound unimportant or superficial.

 3) Putting the EAPI in metadata.xml or in another external file
 
   + it solves 1)
   + it keeps pretty file names
   - it breaks backwards compatibility
   - (specific to metadata.xml) PM will have to learn to read XML (yuck)
 
 That's about it, right?

Good summary, except I think we can find ways to deal with compatibility
(several ideas have been put forth already: giving time for PM to be
upgraded, or a one-time tree or extension bump - and I'm sure there are
even better ones yet to be discussed).  I do not believe that the
filename mangling solution is the one and only way as some people are
insisting.

Also, I'm not sure reading XML is a problem at all - python has good
libs for this already.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Fernando J. Pereda wrote:
 On 10 Jun 2008, at 15:33, Joe Peterson wrote:
 
 Luca Barbato wrote:
 Check if exists a line EAPI=*$, if does and the rest of the string
 matches an understood eapi, go on sourcing, otherwise ignore/mask  
 it...
 And placing it out-of-band (like # EAPI=...) avoids any sourcing
 errors, makes parsing faster, etc.
 
 No, it doesn't make parsing faster. Had you bothered to profile any  
 package manager you'd know that.

No, I have not profiled PMs to try this, but you are saying that reading
the first few lines of a file is not faster than sourcing the whole
thing with bash?  Remember that it could abort the minute it sees a non
'#' or blank line, which would be after the first few.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: GLEP 55

2008-06-10 Thread Joe Peterson
Bernd Steinhauser wrote:
 And that is, what this is about, making EAPI bumps as less painful as 
 possible. The filename is the easiest solution for that.

In any design, there are easy short-cuts that can be taken.  But
sometimes these short-cuts break paradigms that are fundamental.  If you
wanted, you could throw a bunch of things into the filename and make it
255 characters long to avoid reading the file, but that clearly would be
a pretty bad design.

 I really fail to see the point, why it is so important, that the 
 extension will still be .ebuild in the future.
 
 There is a lot of software, that keeps using the same filename for 
 different versions of stuff and in many cases, that is a huge mess.

Is the huge mess you are thinking of the basic reality that software
of any reasonable complexity needs to deal with file formats evolving?
If so, that is exactly why EAPIs now are being introduced.

But almost all software deals with this transparently - no need to
expose it to the user, and sticking the version in the filename is both
fragile (renaming the file can alter it) and seems like a hack.

 I still haven't seen any good reasons against it.

I realize that there are two camps of people here.  One camp sees
mangling the filename extension as an undesirable way to deal with this,
and the other camp simply sees no problem with this.

I want to point out, however, that the fact that you do not see the
issue does not make the issue invalid.  I am sure there are people who
work at Apple who care nothing about the way an iPhone looks or feels
and only care that it works correctly.  If that person went to Steve
Jobs and said, Why are you spending so much money to make this thing
look cool?, he would say that Apple is known for making cool things,
and no one would buy something that works great but looks like a piece
of junk.  He'd be right.

I realize this analogy is a bit of an exaggeration, but there is no
reason we cannot make EAPIs work correctly and very efficiently (this is
where technical innovation comes in), while also keeping the basic
interface (and I include file name convention here) clean, standard,
uncluttered, uncomplicated, and elegant.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Joe Peterson
Richard Freeman wrote:
 On the other hand, this is a big change from the present, and I'm not 
 convinced that it will actually be a big improvement over some of the 
 other EAPI ideas being floated around.  However, it is a 
 potentially-neat idea...

Rich, interesting thoughts!  But yeah, I agree that for now that is a lot.

My idea for the #! thing was much smaller-scale and is a way to add simple
syntax to allow declaration of the EAPI in the file with no sourcing and no
filename extension mangling (plus, no pre-source/post-source issues):

Just have one shebang-like line in the header before any real bash code
(#!EAPI=3, #EAPI=3, or whatever is agreed-upon).  This is out-of-band meta
info, so it's OK that it's in a comment.  It's ignored by bash, but it can be
read trivially without sourcing.  To accelerate things for the tree (I've seen
others mention this idea too), store the EAPI in the portage cache when it is
generated.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] A few questions to our nominees

2008-06-09 Thread Joe Peterson
Donnie Berkholz wrote:
 On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote:
 looks like every nominee wants the council to be more technical so I
 have a few technical questions for you:

 1. GLEP54
 2. GLEP55
 
 I don't have any particular objections to these, besides the vague 
 aesthetic one of having EAPI in the filename. Particularly long, weird 
 EAPIs filled with special characters (to which some will reply So don't 
 do that).

Donnie, I agree, and I think it would be a mistake to use the filename
extension for the EAPI number, even for simple non-long-or-funky
EAPIs.  I know that my reasons will be considered, by some, to be
irrelevant (especially since aesthetics and/or style/elegance are of less
importance to some), but I really think this should be carefully considered;
a mistake here would be quite a shame.  I'll state again (slightly modified)
what I wrote a while back on this issue.

Technical reasons to avoid the filename:

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.
2) Having the same info in more than one place is generally a bad idea in
   any design - this is true in any discipline.  I don't care how many people
   say a) that this is not an issue or b) that it's not a duplication,
   in every data system I've worked on, it has been a very bad idea to have
   more than one version of the same info that can get out of sync with each
   other.  Even if you take great care, I'd still always want to check both
   and not trust either version of the info blindly.  Caching or hashing is
   different (i.e. where the caching mechanism is robust), since the
   system itself keeps the cache up to date, and one version of the info
   is strictly derived from the other rather than both being the source.
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).
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.

Other reasons:

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.
2) It is not an elegant filename policy.  Many systems have elegance as
   a design goal.
3) Assuming going this route is a mistake, it could be hard to reverse.

Currently, I consider Gentoo's ebuild filename conventions simple and
elegant.  In fact, it is beautifully done.  I'd hate to see this go down the
wrong path now.

-Joe

-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-06-09 Thread Joe Peterson
Ciaran McCreesh wrote:
 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.

Yes, if everyone is perfect and remembers to do things perfectly right,
there would never be issues in many things, but when you make something
more complicated, there will be more errors.

 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'.

So why would not a one-time new extension (e.g. .eb) do the trick,
just like .cc works for C programs?  Unless you are talking about
needing to specify the EAPI in the file if the more advanced features
are to be used, but I see nothing wrong with that requirement - it's not
much different than specifying a slot, keywords, whatever.

 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.

No, I get that.  But once you develop the concept of an EAPI, the very
next package manager version can be aware of it and check the EAPI of an
ebuild.  If the ebuild specifies none, then it is old-style.  If it
specifies one that is unknown or newer than what that package manager
version knows it can handle, it can handle that case (ignore it or
whatever).  I don't see why you need to keep bumping the
filename/extension every time it changes from that point forward.

 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.

Not really.  A typical user does not need to know about EAPIs at all,
but he might want to peruse the portage tree to look for ebuilds.  He
might also want to grep for KEYWORDS or whatever.  The user can delve
into it as much as needed or desired, but if there are these mysterious
EAPI numbers tacked onto the extensions, then it's an added complication
that is not important to all users.

 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.

I assume you mean that EAPI needs to be in the file - again, is this
bad?  Many file formats specify a file format version as part of the file.

-Joe

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 55

2008-06-09 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Mon, 09 Jun 2008 20:15:56 -0600
 Joe Peterson [EMAIL PROTECTED] wrote:
 Yes, if everyone is perfect and remembers to do things perfectly
 right, there would never be issues in many things, but when you make
 something more complicated, there will be more errors.
 
 So we shouldn't ever change anything?

Of course I don't mean that.  But humans and computers are each good at
a complementary set of things.  Computers handle obscure complexity
easily; humans do not, so it's better to let computers make our lives
easier rather than the reverse when designing systems.

 So why would not a one-time new extension (e.g. .eb) do the trick,
 just like .cc works for C programs?  Unless you are talking about
 needing to specify the EAPI in the file if the more advanced features
 are to be used, but I see nothing wrong with that requirement - it's
 not much different than specifying a slot, keywords, whatever.
 
 Because then we won't be able to change source compatibility again in
 the future without introducing yet another new extension.

But GLEP 55 is suggesting exactly that: yet another extension for each
new EAPI (I know it is defines this as .ebuild-EAPI, but that is
just semantics).

Source compatibility is not an issue once the EAPI syntax in the file is
defined and the package manager starts to recognize it.  At that point
it can handle the ebuild at whatever EAPI the ebuild declares.  It is
only the older unaware version of the package manager that would get
confused, but that would be solved by a one-time extension change: the
old one would not even look for the new (e.g.) .eb extension (only the
old .ebuild one), which is exactly what GLEP 55 tries to address.  But
the extension change is only needed once.  Once the EAPI syntax is
introduced and the package manager has code to read it, the package
manager is able to determine the EAPI for all future EAPIs.  If some new
syntax in an as-yet unsupported EAPI exists, the EAPI-version-aware
package manager will not trip on it, since it can just not bother to
deal with future EAPI ebuilds.

Now, even if there is no extension change, if we wait long enough, the
chances of an old machine stubbornly staying at an old (pre-EAPI-aware)
portage version gets slimmer and slimmer.  So I'm not even sure this
one-time extension change is really mandatory.  But if it is determined
to be so, I still don't see why we need endless extension changes as
suggested in GLEP 55.

 Because the package manager doesn't know how to extract the EAPI from
 ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild
 might look like this:
 
 require mypackage using ANIMAL=monkey
 
 How do current package managers understand that the EAPI there is 2?

The old (non-aware) package manager version would not, and yes, it would
fail.  So there are two alternatives: wait long enough or do a one-time
extension change.  In the latter case, the package manager would not
even see the new files.  But the new package manager versions would
determine the EAPI from a defined syntax and ignore ebuilds with
future EAPIs.

And I do understand the issue of sourcing, since ebuilds are bash.  If
sourcing is an issue (and I'm not sure it is an overriding one - that's
a good discussion), I would suggest an out-of-band EAPI specifier, but
not in the filename.  Put it in a comment line in the header, like:

# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$
# EAPI=2

inherit eutils
...

So, the first non-blank and non-'#' line (in this case, inherit ...)
would signify the end of the search for the EAPI= string, making parsing
trivial.  Therefore, the only rule would have to be that EAPI= needs
to be in a header comment.  Other rules could be that it needs to be the
only thing on such a header line - whatever.

Again, these are technical details, and I think we can all put our heads
together to come up with the best way to do it.

If sourcing is a better way to go (i.e. to allow EAPI= to be anywhere in
the file with no comment char), caching it might be the answer.  How to
make this efficient would become an implementation detail.

 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.
 Not really.  A typical user does not need to know about EAPIs at all,
 but he might want to peruse the portage tree to look for ebuilds.  He
 might also want to grep for KEYWORDS or whatever.  The user can delve
 into it as much as needed or desired, but if there are these
 mysterious EAPI numbers tacked onto the extensions, then it's an
 added complication that is not important to all users.
 
 The typical user should be using a tool to query that sort of thing.

Sure, but my point is: some users *will* want to explore - why

Re: [gentoo-dev] GLEP 55

2008-06-09 Thread Joe Peterson
Ciaran McCreesh wrote:
 And a file extension is far less obscurely complex than enforcing
 arbitrary syntax restrictions upon ebuilds.

I disagree.  One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.

 No it can't. EAPI has to be known before the source can start. Bash
 doesn't provide traps for executing code upon changed variables.

Doing it out-of-band solve this.

 No, it's only needed once per non-trivial change. So we might as well
 just change it for every EAPI.

Huh?  If the new portage knows how to determine the EAPI definitively
(and that would be defined), it can deal with the differences.

 And then how do we deal with EAPI 3, where the syntax changes again?

Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
from there.  If you change the way you declare EAPI each time, yeah,
that's a problem, but I'm not sure why that would ne necessary.

 Which is way more obscure, complex and arbitrary than a file extension
 change. And it still imposes massive restrictions upon future EAPIs.

Massive?  Simply a one-line EAPI declaration is not massive nor complex.
 And is more elegant than putting it in the filename.

 Every issue you've raised so far was already discussed and debunked the
 first time this discussion happened. Please read the original
 discussions before continuing.

Debunked according to whom?  I believe that some, including you, believe
you debunked them, but I do not believe there was wholesale agreement
from the dev community.

 We had that discussion when the GLEP was first proposed.

Yes, but nothing was decided, and agreement was not reached.  I'd be
very surprized if I were the only one here who is not entirely satisfied
with GLEP 55's solution to this.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009

2008-06-07 Thread Joe Peterson
Vlastimil Babka wrote:
 I'd like to nominate:
 
 zmedico (Zac Medico)

Seconded.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-06 Thread Joe Peterson
William L. Thomson Jr. wrote:
 On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote:
  There could be also switch to add newline 
 before the message but I can't think of a use for it myself.
 The question is how to name the switch :) -n could be confusing as 
 echo -n has the opposite effect. Maybe -b for blank?
 
 Or -p for preceding -t for trailing. Which would make one liner
 
 elog -pt One line with blank ones before and after

The comment from Vlastimil about echo not being part of the elog system
is a very valid point indeed.  As for how to specify that a newline
should be inserted, I think that using elog switches like -n, -p,
etc., as well as putting more than one string on a line present two
problems: the newline would be connected with the elog or ewarn
(or whatever style of output was chosen) and it would also potentially
make the ebuild code harder to read/debug.  For example, if you have a
block of ewarn lines, then a blank line, then a block of elog lines,
you would have to decide in which style to place the special switch (so
portage would not have the opportunity to do auto-context
coloring/formatting).

I personally would prefer a new command like eseparator that could be
treated smartly by portage, taking on the appropriate color based on
what is before and after.  It could also avoid multiple newlines in the
case in which two eseparator lines occur together due to pattern of
conditional blocks in the ebuild invoked under certain circumstances (I
have found this hard to code in a way that covers all possibilities, as
I mentioned before).  Also, separators at the very beginning or very end
of all lines output by the ebuild could be handled consistently (either
ignored or collapsed into an implicit separator, as appropriate) by
portage to produce nice output.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc

2008-06-04 Thread Joe Peterson
William L. Thomson Jr. wrote:
 On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote:
 I think a more ideal solution, less drastic to implement might be
 allowing 2 arguments to be passed. So you could do like

 elog  A blank line precedes this one
 elog A blank line follow this one 
 
 Actually 3, not sure there would be any need for more. 3 for 1 liners
 
 elog  USE flag milf not set 

Well, I'm not sure how that adds anything over just using echo, and if I
simply wanted to statically insert a blank line, I'd rather use echo on
a separate line in the ebuild, since that would be more clear.

The problem with a simple echo is that no * appears on the left to
maintain continuity with the rest of the output - and in a color that
makes sense in the context (maybe this isn't a problem - it depends on
whether that visual continuity is desired).

Also, there are those times when inserting a blank line depends on what
comes after (or before) - and if a * is used, the color depends on
this too.  That can only be solved at a higher level (i.e. in portage).

This is all just food for thought.  I happen to be into aesthetics (and,
BTW, I think Gentoo does a great job already in its use of colors,
etc.), so I think it is important to think about these things, but it's
certainly not the *most* important issue to ponder.  :)

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: packages up for grabs

2008-06-02 Thread Joe Peterson
Has anyone volunteered to take net-misc/ntp?  I know there are alternatives
(like OpenNTPD), but this one is the official one, so I'd hate to see it
slip into substandard quality.  Also, e.g. OpenNTPD is a subset and is less
accurate, so it is not a complete replacement.  I will take it on if no one
else wants it.

-Thanks, Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: packages up for grabs

2008-06-02 Thread Joe Peterson
Joe Peterson wrote:
 Has anyone volunteered to take net-misc/ntp?  I know there are alternatives
 (like OpenNTPD), but this one is the official one, so I'd hate to see it
 slip into substandard quality.  Also, e.g. OpenNTPD is a subset and is less
 accurate, so it is not a complete replacement.  I will take it on if no one
 else wants it.

Ah, never mind; I see this is now part of the base-system herd.  Cool.  :)

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-23 Thread Joe Peterson
Roy Marples wrote:
 config_eth0=1.2.3.4 netmask 255.255.255.0
 5.6.7.8 netmask 255.255.0.0
 routes_eth0=1.2.4.0 netmask 255.255.255.0 gw 1.2.3.6
 5.6.7.9 gw 5.6.7.10
 default gw 1.2.3.1

If one choose to separate by lines, will tabs or spaces be allowed in
subsequent lines?  Like:

config_eth0=1.2.3.4 netmask 255.255.255.0
 5.6.7.8 netmask 255.255.0.0
routes_eth0=1.2.4.0 netmask 255.255.255.0 gw 1.2.3.6
 5.6.7.9 gw 5.6.7.10
 default gw 1.2.3.1

I think this *greatly* improves readability.  Also, the example file
should probably indent for clarity (I know I've talked with you about
this before...).

 address_eth0=1.2.3.4/24 5.6.7.8/16
 routes_eth0=1.2.4.0/24 1.2.3.6 5.6.7.8 5.6.7.10 default 1.2.3.1

That's a little confusing, i.e. not being able to see easily where the
pairs are separated.  What about adopting commas and keeping gw and
netmask (if not CIDR), like:

address_eth0=1.2.3.4/24, 5.6.7.8/16
routes_eth0=1.2.4.0/24 gw 1.2.3.6, 5.6.7.8 gw 5.6.7.10, default gw 1.2.3.1

 Or we could adopt the BSD routing notation and do this
 routes_eth0=route_foo route_bar
 route_foo=1.2.4.0/24 1.2.3.6 metric 5
 route_bar=default 1.2.3.1

Hmm, that might be good as an option, as long as the other way is
available too, but I'd keep gw, etc., perhaps.

 Yes, I've used the same routes_eth0 variable, but we can change it's syntax 
 based on the existance of address_eth0/config_eth0.
 
 So what are peoples feelings on this? Are you happy with the names?
 address_eth0?
 addr_eth0?
 addresses_eth0?
 ipaddress_eth0?
 ipaddr_eth0?
 ipaddresses_ath0?
 routes_eth0?
 static_routes_eth0?
 
 Speak up, or I'll make a decision by myself which will probably be done over 
 the weekend.

I like ipaddr_eth0 or ip_eth0, myself.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-23 Thread Joe Peterson
Roy Marples wrote:
 The point is to remove the hard newline, which you've kept in your examples.

Roy, yes, I realized that after I emailed - at first I thought it was
remaining as an option.  :)

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Council meeting summary for 10 April 2008

2008-04-11 Thread Joe Peterson
Ciaran McCreesh wrote:
 On Thu, 10 Apr 2008 17:37:31 -0700
 Robin H. Johnson [EMAIL PROTECTED] wrote:
 That's why I setup them up with the ability to rsync it, and they
 never got back to me on that, nor used it ever.
 
 Hrm, curious. They seem interested and alive currently. Perhaps it's
 worth another shot...

I also queried them on the forum earlier this year, since none of my
commits were listed.  Here's the link (I do think this is worth looking
into - note that the response what that they did not do CVS...):

http://www.ohloh.net/forums/10/topics/1278

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] New keyword monkey: Kenneth Prug (ken69267)

2008-03-08 Thread Joe Peterson
Robert Buchholz wrote:
 Oh, and great to have you on the team.

I totally welcome Kenneth - I use Gentoo amd64 on a server at work
(mostly using stable keywords, of course).  It's awesome to have a
64-bit OS to take advantage of our Core2 Quad, and it's great to have
yet another person here to keep it going well!

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Seeking questions for a user survey

2008-01-18 Thread Joe Peterson
Steve Long wrote:
 My apologies if I caused you any offense, Joe. I fully agree that choosing
 not to have children is just as mature as deciding to procreate, and more
 mature than simply drifting into parenthood.

No offense taken, and I agree about the drifting into thing.  My
wife's brother asked why we are not having kids, and she asked him, in
turn, why he had kids.  His answer was simply, Because it's what you
do.  I would have rather he said, Because I want to be a parent.

 I suppose what I am getting at is the idea that there are others in Gentoo
 besides young single males. A responsible parent or a committed spouse has
 a very different perspective to a teenager. Certainly my perspective now at
 37 is vastly different to when I was 18. Parenthood changed a great deal,
 as did the earlier process of committing to marriage.

Yep, and I'm one of the older devs here too (in fact, I've got you
beat at 43!).  Good to have a mix of ages, interests, and types of
people, I think.  And ashame we don't have more women.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Seeking questions for a user survey

2008-01-17 Thread Joe Peterson
On Thu, Jan 17, 2008 at 10:56:36AM +, Steve Long wrote:
 Ryan Hill wrote:
 I agree, though year of birth might be interesting.  Income and children
 are a bit too private.

 ++ in general although I do think parenthood (if responsible) is as relevant
 as age. A 28 year old with a 5 year old kid has a lot to show a 35 year old
 doctoral student with no kids, even if it's not all technical. # of kids
 isn't relevant.

Judging the maturity of users (or devs) by how many children they have
(or indeed *if* they have children) is pretty questionable.  I know
people who have kids and are pretty irresponsible (that's not to say
most are, but one does not guarantee the other).  And I'd argue that
someone with children does not necessarily have a lot to show someone
without kids, unless it is the specific experience of childrearing.

There are many people (myself and my wife included) who choose
consciously not to have children.  It is becoming more and more a
*choice* people can legitimately make rather than just an assumed part
of life.  It is not selfish or immature, as some people think, so I'd be
careful about implying that such a question gauges maturity.

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] New developer : Ingmar Vanhassel (ingmar)

2008-01-16 Thread Joe Peterson
Denis Dupeyron wrote:
 It's my pleasure to introduce Ingmar Vanhassel (ingmar) as a new
 Gentoo developer. He will be on the KDE team, as he already has
 extensive experience with the KDE4 overlay. Quoting his mentor in his
 new-dev bug:
 He has rewritten large parts of the KDE4 eclasses, single-handedly
 implemented new pre-releases and [...] worst of all, [...] he has more
 commits than myself (and many of us) and that's, of course, totally
 unacceptable for a mere user so he, too, must be assimilated. ;-)
 
 Ingmar lives in Dudzele, near Brugge, Belgium, and studies economics.
 He has what he calls an inexplicable (but healthy in my book)
 addiction to Jazz music, and plays cello and electric guitar. Besides
 the KDE overlay he spent some time working on traverso, the
 multi-track audio-recorder. He has experience with bash and ruby.

Wow, lots of devs seem to be musicians!  Welcome!

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] New developer : Jean-Noël Rivas seau (elvanor)

2008-01-08 Thread Joe Peterson
Denis Dupeyron wrote:
 Jean-Noël currently lives in Paris, France, but he studied in
 Vancouver, Canada for some time. He is 26 and happily married. Apart
 from computers, he has a passion for games (video, role-playing and
 boardgames), music (progressive metal  rock), and outdoors
 (especially Mountains). No wonder he doesn't have any kids yet.

Great to have a mountain enthusiast!  And why rush on the kids, hey?  ;)

Welcome, Jean-Noël!

-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [gentoo-dev-announce] New developer : Richard Freeman (rich0)

2007-12-23 Thread Joe Peterson
Denis Dupeyron wrote:
 So please everybody, give a warm welcome to Richard.

Richard, big welcome!

-Joe

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-21 Thread Joe Peterson
Assuming that the file extension must change to prevent current PMs from
trying to parse new format ebuilds (and not require waiting a year or
more), I'd be a lot happier seeing it change *once* to a new fixed
extension, with the requirement that the new ebuilds are required to
contain within them them EAPI.  This should future-proof the system.

Preferably, shorten the extension and make a new standard.  I noticed
that .eb seems to be unused
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-20 Thread Joe Peterson
Thomas Pani wrote:
 My concern is technical: Filenames are for identifying files uniquely.
 An ebuild is uniquely identified by cat/pn-pv, so that's what it's
 filename should be. Adding anything else to the filename will only
 clutter the tree and lead to additional inconsitencies. Yes, you can
 check for these using QA tools. But if it's not in the filename you
 don't have to check.
 If you say that package managers need the EAPI info so early that they
 can't even read the first non-comment line of an ebuild that's fine. Go
 and place it in the filename. But nobody had a *technical* argument why
 that's the only possible solution so far. All I got was you don't
 understand all that fancy PM stuff.

Good point.  First of all, and this is an architecture/design issue, the only
valid reason to put the EAPI in the filename is that is *belongs* there in
principal.  File extensions are for file types, not for info that really
should be in the file.  If the motivation for placing the info in the filename
(and worse, the *extension*) is that of performance, you should think twice
about putting it there.  If this is to address a technical problem, it should
be solved in a technical way.  The format of a filename should be determined
by policy, not technical implementation or convenience.

Technical reasons to avoid the filename are:

1) Increase of [needless] complexity in filenames/extensions (and only one
   example of the impact is that searching for ebuild files becomes less
   straightforward).
2) Having the same info in more than one place is bad (requiring extra repoman
   checks and the potential for ambiguity).  I don't care how many people
   say a) that this is not an issue or b) that it's not a duplication,
   in every data system I've worked on, it has been a very bad idea to have
   more than one version of the same info that can get out of sync with each
   other.  Even if you take great care, I'd still always want to check both
   and not trust either version of the info blindly.  Caching or hashing is
   different (i.e. where the caching mechanism is robust), since the
   system itself keeps the cache up to date, and one version of the info
   is stricty derived from the other rather than both being the source.
3) It uses the extension in a way that goes against common use in computers.

Other reasons:

1) Littering the filename with this kind of stuff is potentially confusing do
   both devs and users - I know it's been stated that users don't care, but
   I don't think that's a good assumption.
2) It does not appear to be an elegant filename policy (and this can be
   considered technical as well), since elegance is something designed int
   good systems.
3) Assuming going this route is a mistake, it could be hard to reverse.

I just don't want to see something like this happen as a quick fix without
exploring all of the implications and how it effects what I consider a very
good system (portage/ebuilds) currently.  Also, it seems to me that there are
lots of other alternatives that have been discussed here (and some dismissed
rather quickly).  Portage and its policy are very core to Gentoo, and care
should be taken on this.

-Joe

P.S.  I just joined Gentoo this year, and it is disheartening to see the
nastiness that some people are resorting to on this list.  I've never seen so
much anger and biting remarks in a project, and I can imagine it keeps some
from responding, which is ashame, since issues like this benefit from many
diverse viewpoints.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-19 Thread Joe Peterson
Steve Long wrote:
 Ciaran McCreesh wrote:
 There is no duplication of information, nor redundancy.

 So what were the QA checks you mentioned to confirm that the same EAPI is
 set in both the filename and the ebuild, for-- if not integrity of
 duplicated data?

+1

 Really. It's a heck of a lot cleaner in the filename suffix.

 Nah, it's an awful hack and you know it. It has nothing to do with package
 naming and is unnecessary exposure of internal data.

Yes!  Thank you, Steve!

-Joe
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-18 Thread Joe Peterson
Ulrich Mueller wrote:
 It seems to me that this will inconvenience the users, in order to
 solve a technical problem of the package manager.

Absolutely, +1.  This does indeed sound like a technical issue; how
would requiring a dev to manually mirror the EAPI in the filename
extension provide any benefit over caching it behind the scenes (using
the Manifest file or similar mechanism)?

-Joe
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-18 Thread Joe Peterson
Santiago M. Mola wrote:
 One example was mentioned in this thread before: You cannot use
 find -name '*.ebuild' anymore.

 
 So people could use a bit more elaborated expression to find them.
 Things like this shouldn't be a reason for not applying
 EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be
 fine to publish a quick guide of recipes to migrate scripts which rely
 on the old naming convention and that should be enough.
 
 IMO, keeping us away from improvements to Gentoo because they break
 backwards compatibility with third party scripts is a no-go. Of
 course, this kind of changes can't happen once a month, but they can
 happen from time to time.

I don't think this is about strictly maintaining backwards
compatability.  You are right that we should not let this impede
progress.  My objection is that the proposed scheme does not appear to
make the system more elegant, but rather it creates complexity,
potential errors (mismatches in representions of EAPI), and introduces a
rather unorthodox and complicated file extension pattern.

I also do not see why there are not other more elegant, transparent, and
automatic ways to determine EAPI without sourcing.  I put forth an idea,
and I understand the objections to it, but I'm just brainstorming, and
there *must* be other ways that retain portage's elegance and simplicity.

-Joe
-- 
[EMAIL PROTECTED] mailing list



  1   2   >