# 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
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
# 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
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
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
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,
# 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
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
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
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.
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
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).
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
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
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
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. :)
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.
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
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
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
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
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,
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.
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
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
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
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
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?
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
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
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
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
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)
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
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
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
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
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
# 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
# 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
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
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
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
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
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.
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
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.
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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:
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
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
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
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.
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
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
--
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
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 :
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
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
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
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
[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
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
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
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
Vlastimil Babka wrote:
I'd like to nominate:
zmedico (Zac Medico)
Seconded.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
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.
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
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
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
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:
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
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
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
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
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
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,
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
Denis Dupeyron wrote:
So please everybody, give a warm welcome to Richard.
Richard, big welcome!
-Joe
--
[EMAIL PROTECTED] mailing list
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
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
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
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
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
1 - 100 of 130 matches
Mail list logo
