[gentoo-dev] Stuff that makes people mad
C. Brewer
wrong with this distro? Lately it seems devs just do what the heck they want,
and the only time anyone notices is if someone is polite to give everyone a
heads-up first. This used to be community development, but had gone to thug
development. If we can't get features we ask for, let's just screw it then
and drop all the use flags. Hell, lets get crazy and impose developer term
limits, that way the jaded devs can be recycled and the fresh blood will
keep the momentum going. And since we're all gonna have huge overlays, cut
back to about 20 devs, that ought to do it, since we'll leave the real work
to the end-user.
If you thought all the above was sheer insanity, it doesn't sound too far off
the crap on this ml, or some of the crap on bugzilla::::(
--
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.
--
gento...@gentoo.org mailing list
Andrew Gaffney
> Is it just me, or does any one else get the feeling that something's gone
> wrong with this distro? Lately it seems devs just do what the heck they want,
> and the only time anyone notices is if someone is polite to give everyone a
> heads-up first. This used to be community development, but had gone to thug
> development. If we can't get features we ask for, let's just screw it then
> and drop all the use flags. Hell, lets get crazy and impose developer term
> limits, that way the jaded devs can be recycled and the fresh blood will
> keep the momentum going. And since we're all gonna have huge overlays, cut
> back to about 20 devs, that ought to do it, since we'll leave the real work
> to the end-user.
>
> If you thought all the above was sheer insanity, it doesn't sound too far off
> the crap on this ml, or some of the crap on bugzilla::::(
Wow, someone got up on the wrong side of the bed this morning ;)
First, most (if not all) of the devs are volunteers. They do this in their spare
time. They are not obligated to add every little feature that every user asks
for. Like you said, this is community development. If you really want something,
do it yourself and submit it. It doesn't mean that they give you whatever you
want and you give nothing back.
Second, if the senior (and some not so senior) devs want to be jaded, let them.
They know what they're doing (for the most part) ;)
Last, if you don't like what Gentoo is doing, help fix it or go somewhere else.
--
Andrew Gaffney
Network Administrator
Skyline Aeronautics, LLC.
636-357-1548
--
gento...@gentoo.org mailing list
Robin H. Johnson
> > Is it just me, or does any one else get the feeling that something's
> > gone wrong with this distro? Lately it seems devs just do what the heck
> >they want, and the only time anyone notices is if someone is polite to
> >give everyone a heads-up first.
are the best medium and long term choices for the distribution as a
whole, not the immediate short term solution.
> >This used to be community development, but had gone to thug
> >development. If we can't get features we ask for, let's just screw it
> >then and drop all the use flags.
> First, most (if not all) of the devs are volunteers. They do this in their
> spare time. They are not obligated to add every little feature that every
> user asks for. Like you said, this is community development. If you really
> want something, do it yourself and submit it. It doesn't mean that they
> give you whatever you want and you give nothing back.
If you've got a FULL plan (not just a vague idea), incl. code that
developers are happy with, then we're generally very glad to help you
with it. Code/Changes/Features that break existing systems are much less
likely to get accepted - a bunch of qmail features that have been
proposed to me (incl. some preliminary patches) have been that way, they
would break how the package previous behaved in some way that is
important and relied upon.
> >Hell, lets get crazy and impose developer term limits, that way the
> >jaded devs can be recycled and the fresh blood will keep the
> >momentum going. And since we're all gonna have huge overlays, cut
> >back to about 20 devs, that ought to do it, since we'll leave the
> >real work to the end-user.
Lack of developers is a severe problem in some groups already.
As an example we have _two_ active people that handle KDE. This is
hideously undermanned for something of the scope of KDE.
> >If you thought all the above was sheer insanity, it doesn't sound too far
> >off the crap on this ml, or some of the crap on bugzilla::::(
Vague discussions don't usually end up anywhere productive, but just
like the policy of the linux-kernel mailing list, patches and good
changes are a lot more likely to be accepted, providing there is
somebody willing and able to maintain them (that's the reason a lot of
new ebuilds aren't being accepted right now, as we just don't have
enough manpower).
> Second, if the senior (and some not so senior) devs want to be jaded, let
> them. They know what they're doing (for the most part) ;)
>
> Last, if you don't like what Gentoo is doing, help fix it or go somewhere
> else.
And it would strongly benefit everybody (incl. yourself) if you picked
the former option as I don't think there is really anywhere else to go
without having even more problems than exist presently.
--
Robin Hugh Johnson
E-Mail : rob...@orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
John Nilsson
> Vague discussions don't usually end up anywhere productive, but just
> like the policy of the linux-kernel mailing list, patches and good
> changes are a lot more likely to be accepted, providing there is
> somebody willing and able to maintain them (that's the reason a lot of
> new ebuilds aren't being accepted right now, as we just don't have
> enough manpower).
Can we remove the NEED for a maintainer?
- John
Chris Gianelloni
> Is it just me, or does any one else get the feeling that something's gone
> wrong with this distro? Lately it seems devs just do what the heck they want,
> and the only time anyone notices is if someone is polite to give everyone a
> heads-up first. This used to be community development, but had gone to thug
> development. If we can't get features we ask for, let's just screw it then
> and drop all the use flags. Hell, lets get crazy and impose developer term
> limits, that way the jaded devs can be recycled and the fresh blood will
> keep the momentum going. And since we're all gonna have huge overlays, cut
> back to about 20 devs, that ought to do it, since we'll leave the real work
> to the end-user.
>
> If you thought all the above was sheer insanity, it doesn't sound too far off
> the crap on this ml, or some of the crap on bugzilla::::(
While we're at it, why don't we dissolve all governments and stop using
money. Anarchy and the barter system are just so much better. After
all, it is the *government* that keeps me from making my own money!
Now, let's get back to this little place we like to call reality. There
yet? Good.
All of us Gentoo developers are volunteers. We do this for fun. We do
this unpaid, in our spare time. We all have lives other than Gentoo.
Sometimes, a feature simply cannot be done in the amount of time that
the people requesting it want it done in. Sometimes the feature being
requested simply doesn't have enough demand or enough merit to be
included. Sometimes a feature doesn't get included simply because the
developer maintaining the package simply doesn't have the time nor the
expertise to implement the requested feature.
Being a complete pain about something does no good to serve Gentoo or
yourself. In the end, all you end up doing is looking like how you're
acting. If you want a feature added, send patches. If the developer
refuses to implement the feature, get more support. Contact devrel.
Contact the ombudsman. Follow procedure and you're much more likely to
get what you want than sending obviously inflamatory messages to a
mailing list. Your original email is nothing more than you trying to
start trouble. Think about this. Take an hour to sit back and realize
that this is only software. It isn't like we're murdering baby seals
with a pitchfork by not implementing your feature.
I tend to agree with both sides of the argument on certain valid points
each has. Just remember that this is something we do for fun.
Sometimes we get a bit too heated on what we feel about this great big
mess of stuff we call Gentoo, but in the end, it's just a bunch of ones
and zeros stored magnetically on a platter or two. It really has no
bearing on the essentials of life.
Think about that before raising your blood pressure even more over
something that really isn't that important in the grand scheme of
things.
--
Chris Gianelloni
Developer
Games/LiveCD Teams
Gentoo Linux
Is your power animal a penguin?
Chris Gianelloni
Definitely not. If we were to do something so asinine, we would end up
with packages that are grossly out of date with no hope of them ever
being updated. There would also be nobody responsible for that ebuild,
so there would be nobody liable if something were to go wrong with it.
All in all, it is a very bad idea.
Also, remember that there is *NOTHING* stopping you from creating your
own nice little site, let's call it gentoo-users.somedomain.org, where
you post ebuilds submitted by users but not accepted into the main
portage tree for various reasons.
The guys over at breakmygentoo are a fine example. There are plenty of
developers that don't like it, and plenty then do, but all in all, it is
the users that matter. Simply *because* Gentoo is so community-driven,
can a site like BMG thrive so well. If you don't like what we're doing,
submit to BMG... or make your own site. It's all up to you on what you
do.
Chris Bainbridge
> > Can we remove the NEED for a maintainer?
>
> Definitely not. If we were to do something so asinine, we would end up
> with packages that are grossly out of date with no hope of them ever
> being updated. There would also be nobody responsible for that ebuild,
> so there would be nobody liable if something were to go wrong with it.
> All in all, it is a very bad idea.
One of the things that seems to annoy lots of people is this idea that their
ebuilds are being ignored. I've usually got a bunch (8 at the moment) of
ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a year
old now. There ought to be some sort of procedure for dealing with user
submitted ebuilds. I would suggest a system of putting them in ~x86 (or
whatever) immediately, and if there are no bug reports for x days move them
to x86.
All of this could be easily automated... the idea that every package needs a
maintainer is something that comes from Debian, and is imho unnecessary. You
end up with a few problems: a limited number of maintainers with limited
package interests and a lack of time to devote, and an alienated developer
community who have no way to bug fix or add new ebuilds without going through
the single developer. When that developers interests shift (as they
invariably do), updates to the package become ignored, and once again the
developer community can do nothing to fix this as the power rests with the
maintainer.
There is no need to be defensive and start saying things like "if you don't
like it this way then fork away.." when the desire of the complainer is to
improve gentoo, not start/join another project.
--
gento...@gentoo.org mailing list
Stephen Becker
> There ought to be some sort of procedure for dealing with user
> submitted ebuilds. I would suggest a system of putting them in ~x86 (or
> whatever) immediately, and if there are no bug reports for x days move them
> to x86.
>
The problem with this idea is that the developers would lose control on
consistency and quality of ebuilds in portage. Just because you might
be good at writing an ebuild doesn't mean that everyone knows what they
are doing. We could end up having software installed to silly places
and/or non-standard config file storage, which would be very less than
desirable. There is a reason that we are required to take a test to
become developers, part of that being to know what to do and what not to
do when writing ebuilds and/or accepting them to add to portage.
Steve (aka geoman)
--
gento...@gentoo.org mailing list
Chris Gianelloni
> One of the things that seems to annoy lots of people is this idea that their
> ebuilds are being ignored. I've usually got a bunch (8 at the moment) of
> ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a year
> old now. There ought to be some sort of procedure for dealing with user
> submitted ebuilds. I would suggest a system of putting them in ~x86 (or
> whatever) immediately, and if there are no bug reports for x days move them
> to x86.
If your ebuild is being ignored, it is probably because of one of a few
possible reasons.
1. Developers responsible for that area of Gentoo don't see the value of
it. While this is sometimes a sad thing to think about, it happens. A
good way to solve this is to drum up support for your ebuild. An ebuild
submitted to bugzilla with no comments from other users doesn't *appear*
to have nearly as much support as an ebuild with lots of comments from
users on how they wish this was in portage, and how well it works, etc.
2. Developers responsible for that area of Gentoo don't have the time to
maintain another package they don't understand. In a lot of cases, I
would say that this is the main factor in an ebuild staying in
bugzilla. Once again, a good show of support from users is always a
good motivator. Remember that many developers *never* visit the forums
or #gentoo, so their only real interface with the users is via bugzilla.
3. Developers are busy working on features which affect many more people
and have a much greater demand than your package/ebuild. Unfortunately,
this is one you pretty much have to live with, unless of course you want
to contribute in the effort to get those features implemented, and
therefore give the developers more time to add things like packages and
ebuilds to the tree.
I am sure there are plenty of other reasons that I am missing, but you
start to see the trend. Sometimes simply posting a bug to bugzilla
isn't enough to get your package noticed.
> All of this could be easily automated... the idea that every package needs a
> maintainer is something that comes from Debian, and is imho unnecessary. You
> end up with a few problems: a limited number of maintainers with limited
> package interests and a lack of time to devote, and an alienated developer
> community who have no way to bug fix or add new ebuilds without going through
> the single developer. When that developers interests shift (as they
> invariably do), updates to the package become ignored, and once again the
> developer community can do nothing to fix this as the power rests with the
> maintainer.
As for the idea of *ever* automating any of the additions to ~arch or
arch, I quite frankly think it is a horrible idea. There are many
ebuild submissions to bugzilla which are very good, and there are just
as many that are absolutely appalling. The bad ones can cause some
serious damage to not only Gentoo's quality, but possibly even Gentoo's
stability. Imagine if someone purposefully added a broken/trojaned
package to bugzilla? Imagine if it was glibc?
The idea that every package needs a maintainer has little to do with
Debian, and more to do with the fact that having accountability in one's
actions tends to leave people more honest. It also tends to improve
quality, since the person who added the ebuild will be held accountable
for what the ebuild does to a user's system. The solution to the
"single developer" problem is the Gentoo herd system. There are usually
multiple developers responsible for a single ebuild/set of ebuilds,
rather than a single person.
Given that Gentoo will never have an automated ebuild submission system,
how does having a single developer decide to no longer maintain a
package become any worse than a user submitting an ebuild, it being
added, with no maintainer, mind you, as you would want, then the user
dropping off the face of the planet. Either way you are left with an
unmaintained ebuild, which lowers the quality, and possibly even the
security of our distribution as a whole. After all, what if the
unmaintained package has a security flaw in it that goes unnoticed?
The difference between a package having a Gentoo maintainer or not is
that with a Gentoo maintainer, the chances of something being
unmaintained are much less than simply accepting any ebuild from
anywhere and not having a dedicated maintainer. Usually, when a
developer leaves, devrel and others try to find a new maintainer for
that developer's packages. If it ends up being a long-term problem, we
decide on whether or not the package should remain in the portage tree.
There have been cases where a package was *not* removed simply because
there were users out there submitting fixed ebuilds for newer version,
etc to bugzilla.
Once again, active participation helps much more with Gentoo than any
amount of talk. When users ask, we listen. The more users that request
something, the greater the chances of us doing it. It all boils down to
there being only a limited number of developers and a limited number of
hours in the day. We have to prioritize. A flaw in kde-libs is
probably going to get higher priority than an ebuild for a new
lm-sensors front-end for XFCE, simply due to the numbers affected.
> There is no need to be defensive and start saying things like "if you don't
> like it this way then fork away.." when the desire of the complainer is to
> improve gentoo, not start/join another project.
I completely understand, and as I stated before, drum up some support
for the things you request and you'll get a lot farther in your quests
to improve Gentoo.
Jason Stubbs
Hash: SHA1
On Friday 21 May 2004 23:54, Chris Bainbridge wrote:
> On Friday 21 May 2004 14:39, Chris Gianelloni wrote:
> > > Can we remove the NEED for a maintainer?
> >
> > Definitely not. If we were to do something so asinine, we would end up
> > with packages that are grossly out of date with no hope of them ever
> > being updated. There would also be nobody responsible for that ebuild,
> > so there would be nobody liable if something were to go wrong with it.
> > All in all, it is a very bad idea.
>
> One of the things that seems to annoy lots of people is this idea that
> their ebuilds are being ignored. I've usually got a bunch (8 at the moment)
> of ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a
> year old now.
You're not the first.
> There ought to be some sort of procedure for dealing with user submitted
> ebuilds.
(^^^ he said the magic word 'procedure' :O)
> I would suggest a system of putting them in ~x86 (or whatever) immediately,
> and if there are no bug reports for x days move them to x86.
>
> All of this could be easily automated... the idea that every package needs
> a maintainer is something that comes from Debian, and is imho unnecessary.
Personally, I think every package does need a maintainer. I think that if you
want to equate Gentoo with any community driven *NIX derivative, you should
look at FreeBSD. Every package has a maintainer, but the maintainer is not
necessarily part of the elite few that maintain the base system.
> You end up with a few problems: a limited number of maintainers with
> limited package interests and a lack of time to devote, and an alienated
> developer community who have no way to bug fix or add new ebuilds without
> going through the single developer.
No developer in Gentoo really takes on more than he/she is able to handle
because they know what they're responsibilities are.
> When that developers interests shift (as they invariably do), updates to the
> package become ignored, and once again the developer community can do
> nothing to fix this as the power rests with the maintainer.
A developer becomes a dev when the recruiting developer is sure that the new
dev is in it for the long haul. I do not do any ebuild maintenance at this
stage, but you can be sure that I was fully warned to take full
responsibility for any package I add to the tree for as long as I am part of
this project. If I leave? Well, you must have seen the recruitment posts...
> There is no need to be defensive and start saying things like "if you don't
> like it this way then fork away.." when the desire of the complainer is to
> improve gentoo, not start/join another project.
I don't believe "fork away" was Chris' intended message. I think it was, "if
you don't like things, then lend a helping hand". If your hand is not
received, then go to the ombudsman. bmg ebuilds are not part of the tree, not
because the developers are disliked or that the ebuilds are not necessarily
up to QA but, because of an apparent lack of commitment.
My point? Well, you're saying that Gentoo needs new procedures - what
procedures do you have to offer? I, too, feel that the ebuild development
needs to be opened wider. However, the are many issues to be dealt with:
quality, infrastructure, maintenance...
If you (or anybody) can propose a set of procedures to deal with all these
issues, I'm sure that they will be received with honest criticism at minimum.
Complainers do not add any value.
Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQCVAwUBQK4g91oikN4/5jfsAQK9UAP/ee10aBhmvO+98OwJeaNpTx7DBDPC+ank
aB1EZbgwHzp/KiLuSFWzF5ss98795KEKdeP/wOlPvF86fDIs4zLJkBKuJ3V56rHa
lv7FrfHUY5xRmZN/JatCPYd5b4UUWseFuWr6DuQXoCoKTDe9n1kmIHmGzqSI8omF
oeCYxyANwrQ=
=WOZD
-----END PGP SIGNATURE-----
--
gento...@gentoo.org mailing list
Tom Payne
> On Friday 21 May 2004 14:39, Chris Gianelloni wrote:
> > > Can we remove the NEED for a maintainer?
> >
> > Definitely not. If we were to do something so asinine, we would end up
> > with packages that are grossly out of date with no hope of them ever
> > being updated. There would also be nobody responsible for that ebuild,
> > so there would be nobody liable if something were to go wrong with it.
> > All in all, it is a very bad idea.
>
> One of the things that seems to annoy lots of people is this idea that their
> ebuilds are being ignored. I've usually got a bunch (8 at the moment) of
> ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a year
> old now. There ought to be some sort of procedure for dealing with user
> submitted ebuilds. I would suggest a system of putting them in ~x86 (or
> whatever) immediately, and if there are no bug reports for x days move them
> to x86.
Well, to be honest "good" user-submitted ebuilds tend to have 2-3 bugs in
them, and some user-submitted ebuilds are completely broken. Realistically,
automatically adding them anywhere is going to cause whole heaps of trouble.
I understand your frustration at not having your ebuilds added, but as has
been said many times before it's really due to a shortage of devs. As I dev,
if I add your ebuild to portage I also implicitly take on a responsibility
to maintain it -- version bumps, add features, configs, security fixes, etc.
To be honest this takes a surprising amount of time. Say a new version comes
out, you have to:
- copy the ebuild to a new one with the new version
- download the tarball (might be on a slow link, certainly ties up your
internet connection) to generate the digests
- unpack the tarball somewhere check the docs (README, ChangeLog) to make
sure nothing too drastic has changed
- make sure it compiles correctly
- make sure it installs correctly
- make sure it runs correctly
- commit it to CVS, testing ~arch
- later, move it to stable arch
And this is a simple version bump. Sometimes there are big changes,
especially in config files which often need to be patched to be
'gentooized', sometimes other random things change.
Altogether, it's quite a lot of work and realistically a dev can sensibly
maintain 10-30 ebuilds depending on complexity. There are 6,900 packages in
the tree, so we need 345 devs plus people to work on portage,
infrastructure, devrel, GWN, write docs, etc. etc. We're short at the mo.
Sorry if this all sounds rather pessimistic, but it's the reality for me. In
the meantime, I would suggest that user collections like breakmygentoo.net
are the way forward.
> All of this could be easily automated... the idea that every package needs a
> maintainer is something that comes from Debian, and is imho unnecessary.
Requiring maintainership does require more manpower, but IMHO is very
necessary. Without it we get stale versions, unfixed bugs, unpatched
security holes, a veritable quagmire. Also, it acts as a rationalising force
on the number of ebuilds in portage, encouraging portage to contain useful
ebuilds. Without it, we'd have everybody's private string library in
portage, and their dogs'.
> When that developers interests shift (as they
> invariably do), updates to the package become ignored, and once again the
> developer community can do nothing to fix this as the power rests with the
> maintainer.
This is alleviated somewhat by the herds system. Also, ebuilds do change
maintainership.
To speed up the problem we should perhaps have a please_add_my_ebuild@g.o
alias in Bugzilla. Users can re-assign their ebuilds to this alias if they
feel it's not getting enough attention from the developer it was initially
assigned to. Other devs can then easily browse the list and take ownership
if they choose. This is better than having the bug languish ignored on
someone's personal list.
Regards,
--
Tom
--
gento...@gentoo.org mailing list
Jason Stubbs
Hash: SHA1
On Saturday 22 May 2004 00:39, Chris Gianelloni wrote:
> The idea that every package needs a maintainer has little to do with
> Debian, and more to do with the fact that having accountability in one's
> actions tends to leave people more honest. It also tends to improve
> quality, since the person who added the ebuild will be held accountable
> for what the ebuild does to a user's system. The solution to the
> "single developer" problem is the Gentoo herd system. There are usually
> multiple developers responsible for a single ebuild/set of ebuilds,
> rather than a single person.
Well said.
> Once again, active participation helps much more with Gentoo than any
> amount of talk. When users ask, we listen. The more users that request
> something, the greater the chances of us doing it. It all boils down to
> there being only a limited number of developers and a limited number of
> hours in the day. We have to prioritize. A flaw in kde-libs is
> probably going to get higher priority than an ebuild for a new
> lm-sensors front-end for XFCE, simply due to the numbers affected.
And those reading the above, remember that it is still volunteer work. The
reason that whatever gets higher priority is due to the pride that each
developer takes in their work. Something to think about...
Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQCVAwUBQK4jX1oikN4/5jfsAQK3rAP+I4ofqGvUX7kjvDDG6dXuFI36swOl2Nqv
noi4Mow4Nv2psws0//ZqSl6oSJc/O+cQRkg2MkpTa0Jtv2paVHa7YDoxmurVX6Nw
/4+vVUmQVzour6Q+iq4Hjt2rit7HQgHFckcxbkw1/exMSRx3sVlfhIkCZeFMSBn8
8vuciYzoRe8=
=EluC
Allen Dale Parker
Hash: SHA1
Tom Payne wrote:
<snip>
| To speed up the problem we should perhaps have a please_add_my_ebuild@g.o
| alias in Bugzilla. Users can re-assign their ebuilds to this alias if they
| feel it's not getting enough attention from the developer it was initially
| assigned to. Other devs can then easily browse the list and take ownership
| if they choose. This is better than having the bug languish ignored on
| someone's personal list.
<snip>
IMHO, this is probably the best solution to this particular problem I've
seen since it reared it's head and bit me. Thankfully, if I somehow find
the time to get some docs together, the big project I've wanted gentoo
support for can start rolling (linux-vserver.org). I've come to realize
that I was lucky in finding support (even minor) with the -hardened
guys. For the average joe/jane getting your own ebuild into the tree is
close to impossible unless you're well on your way to dev'hood yourself.
please_add_my_ebuild@g.o or something along those lines *should* be
added to bugzilla, simply because it affords us all something specific
to look through in the search for that out-of-the-way package's ebuild.
Something that we should also address: for the average joe/jane, are
there any tools that do automatic ebuild syntax checking that we should
document somewhere (like the ebuild howto?), how about other QA tools
that the user can impliment on their OWN systems to check and see if
anything's obviously borked? Continuing, do we have any documentation on
current ebuild SOP, stylistic requirements, or other tidbits that aren't
included in the ebuild documentation?
I know that gentoo is a pretty fast moving distribution in it's
evolution. If you stop paying attention for 2 weeks, you're lost. Let's
try to get some of that knowledge stored somewhere that it won't take
the same devs hours of lost time in having to explain the small things
to 10 different users. Let's instead work on documenting as much as
possible. Is there documentation (that's complete) on how to setup your
own gentoo-documentation system for checking out the doc-xml format g.o
is using? How about a list of "approved" tools for banging out docs in
the doc-xml format that g.o uses?
The point of all this rambling is this: our developers are dying under
their current loads, our users have the motivation to help, but not the
ability or the skill required, and we're all suffering for it. Let's try
to get something setup so that we can all speak the same language (and
stay up to date with it!).
- --
Allen Parker
GPG KeyID: 35544083
GPG FP: E628 7310 DE68 321A 933A 5DD1 C831 005C 3554 4083
info...@irc.freenode.net #/tmp #gentoo-dev #gentoo-hardened
info...@irc.oftc.net #vserver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAriocyDEAXDVUQIMRAu71AJ9VxoWaNDr4A1blNZATio6LfnGB9wCcCs7F
4T8Ncdlec2UwrWQ5UMxszBk=
=IR2g
Chris Bainbridge
> My point? Well, you're saying that Gentoo needs new procedures - what
> procedures do you have to offer? I, too, feel that the ebuild development
> needs to be opened wider. However, the are many issues to be dealt with:
> quality, infrastructure, maintenance...
>
> If you (or anybody) can propose a set of procedures to deal with all these
> issues, I'm sure that they will be received with honest criticism at
> minimum. Complainers do not add any value.
I'm sure that something could be done to improve the current situation. I
realise that unmaintained ebuilds aren't a perfect solution; far from it, but
at least they get the languished ebuilds out of bugzilla and into the portage
tree for testing.
How about the creation of a new "unmaintained" group? Ebuilds that nobody
wants to look after get added there so I can emerge
unmaintained/niche_package. Surely this is better than the current situation
(~600 "new package" ebuilds in portage)? When they break users can submit bug
reports or even patches.. nobody has to make any guarantees, after all,
they're obviously unmaintained.
--
gento...@gentoo.org mailing list
Jon Portnoy
> > > Can we remove the NEED for a maintainer?
> >
> > Definitely not. If we were to do something so asinine, we would end up
> > with packages that are grossly out of date with no hope of them ever
> > being updated. There would also be nobody responsible for that ebuild,
> > so there would be nobody liable if something were to go wrong with it.
> > All in all, it is a very bad idea.
>
> One of the things that seems to annoy lots of people is this idea that their
> ebuilds are being ignored. I've usually got a bunch (8 at the moment) of
> ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a year
> old now. There ought to be some sort of procedure for dealing with user
> submitted ebuilds. I would suggest a system of putting them in ~x86 (or
> whatever) immediately, and if there are no bug reports for x days move them
> to x86.
I look at a _lot_ of user-submitted ebuilds and commit some when I feel
I have time to maintain them. However, overall the quality is _nowhere
near_ good enough to allow automatic commits, especially when it means
no real accountability.
The reality of the situation is that most user-submitted ebuilds are
very poor. This is not meant to be harsh to users who submit ebuilds --
many times they're just beginning, and they need a little assistance
and advice.
>
> All of this could be easily automated... the idea that every package needs a
> maintainer is something that comes from Debian, and is imho unnecessary. You
> end up with a few problems: a limited number of maintainers with limited
> package interests and a lack of time to devote, and an alienated developer
> community who have no way to bug fix or add new ebuilds without going through
> the single developer. When that developers interests shift (as they
> invariably do), updates to the package become ignored, and once again the
> developer community can do nothing to fix this as the power rests with the
> maintainer.
We used to not have a dedicated maintainer's system. It was a total
mess. It didn't work out at all. Now we do and we're not going to
suddenly regress on that one.
>
> There is no need to be defensive and start saying things like "if you don't
> like it this way then fork away.." when the desire of the complainer is to
> improve gentoo, not start/join another project.
>
I don't think anyone suggested forking, but rather that there's no need
to have a dependency on Gentoo proper regarding new ebuilds. In fact,
new ebuilds are much more likely to make it into the tree if they've
been up somewhere else being used and reviewed by a large number of
people rather than obscured on Bugzilla.
--
Jon Portnoy
avenj/irc.freenode.net
--
gento...@gentoo.org mailing list
Josh Glover
I agree with both sides, here. It would be lovely to get user-submitted
ebuilds into Portage more quickly, but there are serious QA issues.
I wonder if we can design an ebuild-lint tool to validate ebuilds
automatically. It could work something like this:
1. User submits an ebuild to Bugzilla
2. ebuild-lint runs on it (out of cron, maybe)
3. If ebuild lint finds problems, the user is emailed with a laundry list of
things to fix
4. When ebuild-lint finds no errors with the ebuild, then and only then is the
ebuild brought to the attention of bug-wranglers, who would assign it to the
proper herd.
This way, the number of seriously bad ebuilds would be cut down, so the
signal-to-noise ratio for user-submitted ebuilds should improve greatly,
allowing the devs to give the ebuild a quick once-over before sticking it
Portage (keyword-masked as unstable, of course).
I am sure this idea has flaws, but the basic flow seems good. Comments?
--
Josh Glover
GPG keyID 0xDE8A3103 (C3E4 FA9E 1E07 BBDB 6D8B 07AB 2BF1 67A1 DE8A 3103)
gpg --keyserver pgp.mit.edu --recv-keys DE8A3103
--
gento...@gentoo.org mailing list
Ciaran McCreesh
<c.j.bai...@ed.ac.uk> wrote:
| How about the creation of a new "unmaintained" group? Ebuilds that
| nobody wants to look after get added there so I can emerge
| unmaintained/niche_package. Surely this is better than the current
| situation (~600 "new package" ebuilds in portage)? When they break
| users can submit bug reports or even patches.. nobody has to make any
| guarantees, after all, they're obviously unmaintained.
Except that people would actually use it, despite all the warnings to
the contrary, and then they'll moan when their system gets totally
screwed up. Marking something as "do not use this if you care about your
system" will just encourage certain (rather vocal) users to try it. Said
users will then carry on submitting unrelated bugs, even though we tell
them not to.
A "tainted" flag in "emerge info" wouldn't help either. We already have
users who deliberately lie about what CFLAGS and gcc version they're
using when submitting bugs.
Also, this tree would have to be kept *entirely* separate from the main
tree. It's possible for a rogue ebuild to screw up the entire tree. This
brings us back to BMG, for example.
--
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
Mail: ciaranm at gentoo.org
Web: http://dev.gentoo.org/~ciaranm
Jon Portnoy
A lint checking tool can't check things like incorrect (R)DEPEND
statements, a bad LICENSE=, ebuild flow issues, not passing CFLAGs
properly, etc. Many times user-submitted ebuilds are syntactically correct,
but still need significant fixing.
I agree that it would be a start to cut down on noise, though.
Ciaran McCreesh
<jmg...@gentoo.org> wrote:
| I wonder if we can design an ebuild-lint tool to validate ebuilds
| automatically. It could work something like this:
| This way, the number of seriously bad ebuilds would be cut down, so
| the signal-to-noise ratio for user-submitted ebuilds should improve
| greatly, allowing the devs to give the ebuild a quick once-over before
| sticking it Portage (keyword-masked as unstable, of course).
You mean repoman, which can (and should) already be run by
non-developers? As far as I'm concerned, any user-submitted ebuild which
*doesn't* repoman cleanly (metadata et al excluded, of course) is
grounds for an immediate WONTFIX.
Of course, you can have a repoman-clean ebuild which is still insanely
broken, but it's a start...
Chris Bainbridge
> Except that people would actually use it, despite all the warnings to
> the contrary, and then they'll moan when their system gets totally
> screwed up. Marking something as "do not use this if you care about your
> system" will just encourage certain (rather vocal) users to try it. Said
> users will then carry on submitting unrelated bugs, even though we tell
> them not to.
>
> A "tainted" flag in "emerge info" wouldn't help either. We already have
> users who deliberately lie about what CFLAGS and gcc version they're
> using when submitting bugs.
There will always be a minority of people who are rude and dishonest in any
endeavour. We should not let this dissuade us from action.
> Also, this tree would have to be kept *entirely* separate from the main
> tree. It's possible for a rogue ebuild to screw up the entire tree. This
> brings us back to BMG, for example.
Ebuilds are trapped in their own directory, I don't see how adding them messes
up other ebuilds. Unless you mean that they can do bad things like
overwriting libc, which would be pretty obvious and reported straight away by
users of the ebuild.
--
gento...@gentoo.org mailing list
Ciaran McCreesh
<c.j.bai...@ed.ac.uk> wrote:
| > Also, this tree would have to be kept *entirely* separate from the
| > main tree. It's possible for a rogue ebuild to screw up the entire
| > tree. This brings us back to BMG, for example.
|
| Ebuilds are trapped in their own directory, I don't see how adding
| them messes up other ebuilds. Unless you mean that they can do bad
| things like overwriting libc, which would be pretty obvious and
| reported straight away by users of the ebuild.
All you have to do is add in one little call that does something naughty
in global scope and you can nuke the entire tree from an ebuild.
John Nilsson
> On Fri, 2004-05-21 at 09:19, John Nilsson wrote:
> > Can we remove the NEED for a maintainer?
>
> Definitely not. If we were to do something so asinine, we would end up
> with packages that are grossly out of date with no hope of them ever
> being updated. There would also be nobody responsible for that ebuild,
> so there would be nobody liable if something were to go wrong with it.
> All in all, it is a very bad idea.
When I emphasized "NEED" I didn't mean the official requirement I menat
the practical/technical requirement.
I meant: Can we engineer a solution to the problem removing the need for
maintainers but still meeting the requirements?
I view an ebuild as a kind of hack at the moment. Ebuilds solve the
problem that open source software packages does not meet the
requirements of their users (distributors).
Ebuilds provide a uniform interface for configuring and installing.
Fair, does that need one maintainer per package?
Ebuild provide metadata for dependencies. Is this really the
responsibility of Gentoo or even Portage? I say, move that to the source
packager.
Ebuilds provide an "install shield" so that installed files can be
tracked, protected, removed, updated. Would it be correct to patch this
functionality into install(1) instead?
Ebuilds makes sure that files go to the right places. A broken install
system is a broken install system. Patch automake/autoconf their purpose
is to make portability a breeze, why do we have another in house layer
on top?
...you get my drift.
-John
Jon Portnoy
Because you're trying to force various tools to do things they're not
designed for. What's the point?
Tom Payne
> Fair, does that need one maintainer per package?
>
> Ebuild provide metadata for dependencies. Is this really the
> responsibility of Gentoo or even Portage? I say, move that to the source
> packager.
>
> Ebuilds provide an "install shield" so that installed files can be
> tracked, protected, removed, updated. Would it be correct to patch this
> functionality into install(1) instead?
>
> Ebuilds makes sure that files go to the right places. A broken install
> system is a broken install system. Patch automake/autoconf their purpose
> is to make portability a breeze, why do we have another in house layer
> on top?
<sarcasm>
Ah, that's the solution: we don't change Gentoo, we change every single
other piece of software in the world!
</sarcasm>
Realistically, nice idea but it's a fantasy. Do I need to explain why?
Not meaning to be too rude, but it's hard not to :-)
Jason Stubbs
Hash: SHA1
On Saturday 22 May 2004 01:59, John Nilsson wrote:
> On Fri, 2004-05-21 at 15:39, Chris Gianelloni wrote:
> > On Fri, 2004-05-21 at 09:19, John Nilsson wrote:
> > > Can we remove the NEED for a maintainer?
> >
> > Definitely not. If we were to do something so asinine, we would end up
> > with packages that are grossly out of date with no hope of them ever
> > being updated. There would also be nobody responsible for that ebuild,
> > so there would be nobody liable if something were to go wrong with it.
> > All in all, it is a very bad idea.
>
> When I emphasized "NEED" I didn't mean the official requirement I menat
> the practical/technical requirement.
>
> I meant: Can we engineer a solution to the problem removing the need for
> maintainers but still meeting the requirements?
I'll let you guys continue ^^^
> Ebuild provide metadata for dependencies. Is this really the
> responsibility of Gentoo or even Portage? I say, move that to the source
> packager.
>
> Ebuilds provide an "install shield" so that installed files can be
> tracked, protected, removed, updated. Would it be correct to patch this
> functionality into install(1) instead?
>
> Ebuilds makes sure that files go to the right places. A broken install
> system is a broken install system. Patch automake/autoconf their purpose
> is to make portability a breeze, why do we have another in house layer
> on top?
>
> ...you get my drift.
The drift I'm getting is that you're not asking for a portable source
configurator from autoconf, but that you're asking to tie it to a single
platform (or a set fo platforms that understand a single regime). autoconf
works on many *NIX platforms becuase it only relies on the basic tools that
*NIX platforms provide. If you want it to extend further than that, you need
to convince the people that define the *NIX platform to extend it futher. I'm
not saying that's a bad thing... However, I'm not prepared to do it. Are you?
Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQCVAwUBQK47k1oikN4/5jfsAQI/gwQAsw41aS1PHvhpDZHY1G1xCZBhNkp9J1bo
Xp1hWxy4vNyEEH8DeVHN+dQaJdqZ+LljJwduuaHOWHHYyUO1TW4QOhc0LcSYxX2a
mbKWO/IdQ7NkHsLcxfFTHhQ4PtBba3eKUJU+R22QAxjR/B676h7iu6a4BjNFyKDo
8CkhNL6BY68=
=7TyL
Josh Glover
> On Fri, 21 May 2004 12:29:19 -0400 (EDT) "Josh Glover"
>
> | I wonder if we can design an ebuild-lint tool to validate ebuilds
> | automatically. It could work something like this:
>
> You mean repoman, which can (and should) already be run by
> non-developers? As far as I'm concerned, any user-submitted ebuild which
> *doesn't* repoman cleanly (metadata et al excluded, of course) is
> grounds for an immediate WONTFIX.
Does repoman check for FHS compliance and the like as well?
If repoman should be run by users before submitting an ebuild, we need to add
it to the Ebuild HOWTO, or the Submitting Ebuilds HOWTO. Also, repoman's
feedback needs to be easy enough to understand.
The key point to my proposal, however, is automating the lint script, whether
it is repoman or a new tool.
The problem with marking user-submitted ebuilds that fail repoman WONTFIX is
that we might lose potential developers. Better that the user is educated than
slapped away. And if the education can take place without interaction from a
dev (at least, education on the basics of ebuild writing), so much the better.
Jason Stubbs
Hash: SHA1
On Saturday 22 May 2004 01:12, Chris Bainbridge wrote:
> On Friday 21 May 2004 16:32, Jason Stubbs wrote:
> > My point? Well, you're saying that Gentoo needs new procedures - what
> > procedures do you have to offer? I, too, feel that the ebuild development
> > needs to be opened wider. However, the are many issues to be dealt with:
> > quality, infrastructure, maintenance...
> >
> > If you (or anybody) can propose a set of procedures to deal with all
> > these issues, I'm sure that they will be received with honest criticism
> > at minimum. Complainers do not add any value.
>
> I'm sure that something could be done to improve the current situation.
That something is what I'm asking if you (or somebody else) can produce...
> I realise that unmaintained ebuilds aren't a perfect solution; far from it,
> but at least they get the languished ebuilds out of bugzilla and into the
> portage tree for testing.
I agree with Ciaran here in that it is worse that them sitting in bugzilla.
> How about the creation of a new "unmaintained" group? Ebuilds that nobody
> wants to look after get added there so I can emerge
> unmaintained/niche_package. Surely this is better than the current situation
> (~600 "new package" ebuilds in portage)? When they break users can submit
> bug reports or even patches.. nobody has to make any guarantees, after all,
> they're obviously unmaintained.
I agree again. Ask in #gentoo how many users are using gcc 3.4...
Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQCVAwUBQK4/GFoikN4/5jfsAQJeCAP9Epj8ndD3wa889J39zbT3ur05IIZeGKUb
+nFllloqMd0eM3/kdNb2F6Oytk8PwVR/0IuFAUyYyeedkYDMV6pHk4Sn4l1LSx30
kXBLbDHaWUOiG6eoH6AW0Q1W5mtOiM1SHhiXCxz/brFtKD4lucq9gbP7AG/9EaKP
dWEwwts2kQE=
=Mfyk
Ciaran McCreesh
<jmg...@gentoo.org> wrote:
| Quoth Ciaran McCreesh:
| > On Fri, 21 May 2004 12:29:19 -0400 (EDT) "Josh Glover"
| >
| > | I wonder if we can design an ebuild-lint tool to validate ebuilds
| > | automatically. It could work something like this:
| >
| > You mean repoman, which can (and should) already be run by
| > non-developers? As far as I'm concerned, any user-submitted ebuild
| > is grounds for an immediate WONTFIX.
|
| Does repoman check for FHS compliance and the like as well?
Uh, no. But then, we're not aiming for FHS compliance anyway. Repoman
can't do anything beyond basic checks -- no way we could make an app
that's sufficiently intelligent. Also remember that repoman can't even
try to build the app in question (it'd fail if someone ever tried to
commit a silo change from an x86 box, for example).
| The problem with marking user-submitted ebuilds that fail repoman
| WONTFIX is that we might lose potential developers. Better that the
| user is educated than slapped away.
Sure, I paste the repoman output along with a description of what this
means as well as the WONTFIX. If the submitter feels like fixing the
bug, they are of course free to reopen, but failing a repoman check is a
fairly strong indication that the ebuild is badly screwed up.
Christian Gut
I to agree with both sides. But what about integrating an easy way to
add custom rsync or perhaps ftp/http repositorys stackable to portage?
like debian does it with apt. If there is a user maintaining ebuilds
which can't get into the gentoo tree, he sets up his own tree and
maintains them there. If others want that ebuilds, they add his tree to
their .. make.conf.
Yes I know about overlay but i think of a more flexible way... the sites
like breakmygentoo could maintain repositories with untested ebuilds and
users are on their own testing/using them but it would perhaps help to
grow people writing better ebuilds and wanting to becume gentoo devs.
I like the debian way doing this. I don't like it for basic things like
java or something, but I think this would also help commercial
developers integrating their software within gentoo
--
gento...@gentoo.org mailing list
Chris Gianelloni
> Ebuilds are trapped in their own directory, I don't see how adding them messes
> up other ebuilds. Unless you mean that they can do bad things like
> overwriting libc, which would be pretty obvious and reported straight away by
> users of the ebuild.
Don't you see, this is *exactly* what we want to avoid. Why should we
have to take the time to try and fix a rogue ebuild that was
*automatically* added to the tree? Especially considering the amount of
time that can be wasted in fixing something like a broken libc.
Marius Mauch
> I to agree with both sides. But what about integrating an easy way to
> add custom rsync or perhaps ftp/http repositorys stackable to portage?
> like debian does it with apt. If there is a user maintaining ebuilds
> which can't get into the gentoo tree, he sets up his own tree and
> maintains them there. If others want that ebuilds, they add his tree
> to their .. make.conf.
We're working on it, see bug 35535.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
Chris Gianelloni
> When I emphasized "NEED" I didn't mean the official requirement I menat
> the practical/technical requirement.
>
> I meant: Can we engineer a solution to the problem removing the need for
> maintainers but still meeting the requirements?
No. One of the requirements is that someone is responsible for that
piece of software and what it does on YOUR system. Would you prefer we
just arbitrarily assign out responsibility for packages? I vote that
YOU get to take over OpenOffice, KDE, Gnome, GCC, and glibc. I'll take
bash. ;]
> I view an ebuild as a kind of hack at the moment. Ebuilds solve the
> problem that open source software packages does not meet the
> requirements of their users (distributors).
Actually, LFS has proven that the software packages are pretty much OK
amongst themselves, it is when you start bringing in numerous variables
of versions, revisions, configure options, etc. that you start to get
into the complexity that ebuilds try to relieve. Nobody is forcing you
to use emerge. Remember that.
> Ebuilds provide a uniform interface for configuring and installing.
> Fair, does that need one maintainer per package?
Yes. Though I know that personally, I probably maintain 20-30
packages. As a member of the 2 herds I am in (games/livecd), I would
venture that number is closer to 200-300. Did I mention that there's
only 4 of us (3 active) in games? The livecd herd at this time is just
me.
> Ebuild provide metadata for dependencies. Is this really the
> responsibility of Gentoo or even Portage? I say, move that to the source
> packager.
I wouldn't mind seeing this done upstream. I'm not sure how it would be
done, but it would definitely make all of our lives much easier.
> Ebuilds provide an "install shield" so that installed files can be
> tracked, protected, removed, updated. Would it be correct to patch this
> functionality into install(1) instead?
...or RPM, or apt, or yum, or pkgtools, or...
As you see, there are many competing packaging systems. What you
propose would require everyone to agree on one. If you've learned
anything about Linux, it is that everyone is out to build a better
mousetrap.
> Ebuilds makes sure that files go to the right places. A broken install
> system is a broken install system. Patch automake/autoconf their purpose
> is to make portability a breeze, why do we have another in house layer
> on top?
Pretty much read above.
What you propose really is for Linux to unify. There would be no need
for Gentoo, or Debian, or Red Hat. It would all just be Linux. It
would all work the same and it would all feel the same.
Well, sir. I wish you luck in the endeavour. Until then, I'll be here
working on ebuilds and trying to make what we have today better.
Stuart Herbert
> Can we remove the NEED for a maintainer?
>
When I first became a dev, I wrote a draft procedure for ebuild sponsoring.
You can read it here:
http://dev.gentoo.org/~stuart/sponsorship/Sponsorship-Draft02.pdf
It could use a little updating, but it defines clear criteria that might work
on a wider scale.
Best regards,
Stu
--
Stuart Herbert stu...@gentoo.org
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
Chris Gianelloni
> I to agree with both sides. But what about integrating an easy way to
> add custom rsync or perhaps ftp/http repositorys stackable to portage?
> like debian does it with apt. If there is a user maintaining ebuilds
> which can't get into the gentoo tree, he sets up his own tree and
> maintains them there. If others want that ebuilds, they add his tree to
> their .. make.conf.
An interesting idea, and one that has been proposed a dozen times
before. Look below for reasons why it is a bad idea.
> Yes I know about overlay but i think of a more flexible way... the sites
> like breakmygentoo could maintain repositories with untested ebuilds and
> users are on their own testing/using them but it would perhaps help to
> grow people writing better ebuilds and wanting to becume gentoo devs.
Guess what happens when something goes wrong? Do you know where the bug
report goes? I sure do. What if you use a BMG ebuild for GCC or glibc
and everything *seems* fine. Then you build python with it. Then you
even "upgrade" back to the "official" GCC/glibc. Guess what? Your
python is still compiled with the unofficial GCC and when you submit a
portage bug, it could very well be caused by the fact you were *at one
time* using an unofficial ebuild for GCC. Don't think it can happen?
Go look at bugzilla.
Once again, the general consensus from the people actually responsible
for maintaining Gentoo is that there's nothing wrong with "unofficial"
ebuilds of any kind, but *we* cannot be held responsible for what *you*
do to your system when running ebuilds *not* made/maintained by us.
Period.
There's absolutely nothing stopping you from coding up a "multiple tree"
version of portage and getting people to use it. However, in the sake
of sanity and QA, there is no way that we could sanction it officially
without taking the quality of Gentoo as a whole down the toilet.
Stuart Herbert
> One of the things that seems to annoy lots of people is this idea that
> their ebuilds are being ignored. I've usually got a bunch (8 at the moment)
> of ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a
> year old now.
I can't speak for other people, but what works with me is when people take the
trouble to come and talk to me about their pending ebuild. It also helps
when people talk to me about packages that I might personally find
interesting. That makes me more motivated to take on the commitment that
goes with adding an ebuild into Portage.
> There ought to be some sort of procedure for dealing with
> user submitted ebuilds.
Just the other night, Zul and I were talking about this. We organise Bug Day
once a month. Maybe we should organise a New Ebuild Day once a month too.
> I would suggest a system of putting them in ~x86
> (or whatever) immediately, and if there are no bug reports for x days move
> them to x86.
This sounds like the perfect way for someone to use Gentoo to distribute
unpleasant or downright malicious software around the Internet.
Please, keep the ideas coming, but that one is never going to fly. It's far
too open to abuse; and the idea that users will take personal responsibility
for what they install has been proven time and time again to be a false idea.
> All of this could be easily automated... the idea that every package needs
> a maintainer is something that comes from Debian, and is imho unnecessary.
I'm pretty sure that Patrick and the hard-working folks over at Slackware
would disagree with you on Debian inventing the idea of packages needing
maintainers ;-) I had some small involvement with Slackware 3.0.3, and while
Patrick didn't have per-package maintainers like we have today, nothing went
into the distribution without him having checked all the contributions and
patches first.
> You end up with a few problems: a limited number of maintainers with
> limited package interests and a lack of time to devote, and an alienated
> developer community who have no way to bug fix or add new ebuilds without
> going through the single developer.
I don't believe this is quite accurate. Our problem is that the 'alienated
developer community' you're refering to ** aren't ** developers on the Gentoo
project. They want to see their packages included in Gentoo, but they're not
coming forward and saying 'I want to join the team'.
The developer community are the people who have commit access to the Gentoo
CVS tree. I don't say that to create a 'them and us' division. What I'm
saying is that the developer community is where we need people to be - and
right now we don't have enough people taking part.
> When that developers interests shift
> (as they invariably do), updates to the package become ignored, and once
> again the developer community can do nothing to fix this as the power rests
> with the maintainer.
This is an area where the managers in Gentoo could add more value ;-)
Although we have people in 'manager' positions, most of them provide a lot of
leadership rather than management. Leadership's good - we need lots of that.
But we also need real management tasks - like knowing which ebuilds have
become unmaintained.
Why do you say that the power rests with the maintainer?
And why do you see 'maintainers' as something separate from the developer
community? I'm genuinely curious.
> There is no need to be defensive and start saying things like "if you don't
> like it this way then fork away.." when the desire of the complainer is to
> improve gentoo, not start/join another project.
You can improve Gentoo by joining the project. I believe the email address
you're looking for is 'recru...@gentoo.org'.
About a year ago, I had very similar complaints to yours, about not getting
changes into Portage. The response I had from Kurt and Seemant was the same
as we're all telling you. Get involved by becoming a volunteer Gentoo dev.
And you know what? They were right.
Joseph Booker
Marius Mauch said:
> On 05/21/04 Christian Gut wrote:
>
>> I to agree with both sides. But what about integrating an easy way to
>> add custom rsync or perhaps ftp/http repositorys stackable to portage?
>> like debian does it with apt. If there is a user maintaining ebuilds
>> which can't get into the gentoo tree, he sets up his own tree and
>> maintains them there. If others want that ebuilds, they add his tree
>> to their .. make.conf.
>
> We're working on it, see bug 35535.
Isn't this what gensync in gentoolkit-dev does?
--
Joe Booker
--
gento...@gentoo.org mailing list
John Nilsson
> On Saturday 22 May 2004 01:59, John Nilsson wrote:
> > Ebuilds makes sure that files go to the right places. A broken install
> > system is a broken install system. Patch automake/autoconf their purpose
> > is to make portability a breeze, why do we have another in house layer
> > on top?
> >
> > ...you get my drift.
>
> The drift I'm getting is that you're not asking for a portable source
> configurator from autoconf, but that you're asking to tie it to a single
> platform (or a set fo platforms that understand a single regime). autoconf
> works on many *NIX platforms becuase it only relies on the basic tools that
> *NIX platforms provide. If you want it to extend further than that, you need
> to convince the people that define the *NIX platform to extend it futher. I'm
> not saying that's a bad thing... However, I'm not prepared to do it. Are you?
Ok that came off wrong. What I meant is that we shouldn't have to
specify in each ebuild where and how to put files.
after a "./configure" a "make install" should follow the gentoo
standard, no extra patching required (i.e. dodoc, doexe and that stuff).
-John
Stuart Herbert
> Ok that came off wrong. What I meant is that we shouldn't have to
> specify in each ebuild where and how to put files.
>
> after a "./configure" a "make install" should follow the gentoo
> standard, no extra patching required (i.e. dodoc, doexe and that stuff).
Where is the benefit here?
If you don't provide a src_compile() in your ebuild, Portage supplies one for
you. I haven't looked at it recently, but if it doesn't run configure and
make install, I'm sure it could be made to.
Maintainers are evil, so let's get rid of them. But you're not going to get
ebuilds debugged, packages bumped, etc etc without someone doing the work.
So you end up becoming the maintainer. Back to square one.
It's exactly the same vicious cycle of reasoning that contractors have with
their agents-are-scum-let's-get-rid-of-agents desire ;-)
Mike Frysinger
> Uh, no. But then, we're not aiming for FHS compliance anyway.
well we do ... we just dont bend over backwards for it
-mike
--
gento...@gentoo.org mailing list
John Nilsson
> On Fri, 2004-05-21 at 12:59, John Nilsson wrote:
> > When I emphasized "NEED" I didn't mean the official requirement I menat
> > the practical/technical requirement.
> >
> > I meant: Can we engineer a solution to the problem removing the need for
> > maintainers but still meeting the requirements?
>
> No. One of the requirements is that someone is responsible for that
> piece of software and what it does on YOUR system. Would you prefer we
> just arbitrarily assign out responsibility for packages? I vote that
> YOU get to take over OpenOffice, KDE, Gnome, GCC, and glibc. I'll take
> bash. ;]
I'm just talking about ebuilds, not the entire software world! =) If we
can remove the need for ebuilds no one has to maintain them. The problem
I see is that the work spent on maintaining ebuilds (installation
scripts for one linux distribution) could be spent on the actual
software instead, benefiting all systems.
> > I view an ebuild as a kind of hack at the moment. Ebuilds solve the
> > problem that open source software packages does not meet the
> > requirements of their users (distributors).
>
> Actually, LFS has proven that the software packages are pretty much OK
> amongst themselves, it is when you start bringing in numerous variables
> of versions, revisions, configure options, etc. that you start to get
> into the complexity that ebuilds try to relieve. Nobody is forcing you
> to use emerge. Remember that.
Ebuild solve a very real problem. That is why I use them. I'm just
asking if it is the best solution.
> > Ebuilds provide a uniform interface for configuring and installing.
> > Fair, does that need one maintainer per package?
>
> Yes. Though I know that personally, I probably maintain 20-30
> packages. As a member of the 2 herds I am in (games/livecd), I would
> venture that number is closer to 200-300. Did I mention that there's
> only 4 of us (3 active) in games? The livecd herd at this time is just
> me.
But doesn't autoconf provide the same thing?
> > Ebuild provide metadata for dependencies. Is this really the
> > responsibility of Gentoo or even Portage? I say, move that to the source
> > packager.
>
> I wouldn't mind seeing this done upstream. I'm not sure how it would be
> done, but it would definitely make all of our lives much easier.
I can think of many ways, ebuilds being one of them. The question is
rather why. Someone has to maintain the information.
> > Ebuilds provide an "install shield" so that installed files can be
> > tracked, protected, removed, updated. Would it be correct to patch this
> > functionality into install(1) instead?
>
> ...or RPM, or apt, or yum, or pkgtools, or...
again a job for ./configure
> As you see, there are many competing packaging systems. What you
> propose would require everyone to agree on one. If you've learned
> anything about Linux, it is that everyone is out to build a better
> mousetrap.
Any form of interoperability would do.
> > Ebuilds makes sure that files go to the right places. A broken install
> > system is a broken install system. Patch automake/autoconf their purpose
> > is to make portability a breeze, why do we have another in house layer
> > on top?
>
> Pretty much read above.
>
> What you propose really is for Linux to unify. There would be no need
> for Gentoo, or Debian, or Red Hat. It would all just be Linux. It
> would all work the same and it would all feel the same.
No what I propose is that move as much of the ebuilding as possible to
the package developers (in a portable way). And provide system agnostic
tools for the rest.
There would still be a need to patch and fork packages to suit Gentoo.
Generally make things stable and consistent. I'm only talking about
relieving some of the portage work from Gentoo developers and push it
upstream where all systems could benefit from it.
> Well, sir. I wish you luck in the endeavour. Until then, I'll be here
> working on ebuilds and trying to make what we have today better.
I hope you do. I'll try to do my bit to. =)
-John
John Nilsson
> On Friday 21 May 2004 22:59, John Nilsson wrote:
> > Ok that came off wrong. What I meant is that we shouldn't have to
> > specify in each ebuild where and how to put files.
> >
> > after a "./configure" a "make install" should follow the gentoo
> > standard, no extra patching required (i.e. dodoc, doexe and that stuff).
>
> Where is the benefit here?
>
> If you don't provide a src_compile() in your ebuild, Portage supplies one for
> you. I haven't looked at it recently, but if it doesn't run configure and
> make install, I'm sure it could be made to.
In the end I would like a system where I can install a tar.gz install it
and have it maintained/updated by portage without the need for an
ebuild. This would of course only work for packages that don't need
extra gentoo fitting.
> Maintainers are evil, so let's get rid of them. But you're not going to get
> ebuilds debugged, packages bumped, etc etc without someone doing the work.
> So you end up becoming the maintainer. Back to square one.
I don't think maintainers are evil. I think they/you do a terrific job
and I thank you all! I just feel that some of the work could be pushed
upstream, and some of the choices pushed downstream.
-John
Joseph Booker
ok, i totally get it:
You would like every single package to conform to gentoo's way of
packaging them so they dont have to be changed when emerged. This includes
kde installing itself by default in /usr/kde/<version> on all distros and
all enviromental variables in /etc/env.d/ and for everything to use
./configure scripts (think of the -bin's!!!), for all the kernels to
support koutput, for all the binarys to install by default to
/opt............
This is a distrobution, you seem to want to get rid of that and go with an
LFS-like solution
those ./configure scripts are uniform thoughout the unix world for one
reason: its good coding that does its job
if you can code some system that works with packages as well as autoconf
or make does, then try doing that before asking gentoo devs to push such
an inititive
Joseph Booker
John Nilsson said:
> In the end I would like a system where I can install a tar.gz install it
> and have it maintained/updated by portage without the need for an
> ebuild. This would of course only work for packages that don't need
> extra gentoo fitting.
that seems like the way slackware works, except that tar.gz is installed
using pkg-add or something like that............is that the kind of
package managment you want?
John Nilsson
> ok, i totally get it:
no.
> You would like every single package to conform to gentoo's way of
> packaging them so they dont have to be changed when emerged. This includes
> kde installing itself by default in /usr/kde/<version> on all distros and
> all enviromental variables in /etc/env.d/ and for everything to use
> ./configure scripts (think of the -bin's!!!), for all the kernels to
> support koutput, for all the binarys to install by default to
> /opt............
no, I would like every single package to provide the information needed
to be portable. Most useflags is probably of the --enable-<useflag>
kind. Why maintain a separate list of configure options and package
dependencies when the configure scripts already contain a list of
options and easily could be extended to provide dependency information?
Where to install files is probably hard to extend more, there already
exists functionality for that.
> This is a distrobution, you seem to want to get rid of that and go with an
> LFS-like solution
I would like portage to evolve into tools and patches so that the LFS
experience would be somewhat gentooish. Gentoo the distribution is
great. I just feel that portage could evolve outside Gentoo.
> those ./configure scripts are uniform thoughout the unix world for one
> reason: its good coding that does its job
>
> if you can code some system that works with packages as well as autoconf
> or make does, then try doing that before asking gentoo devs to push such
> an inititive
I'm not asking anyone to do anything, I'm suggesting. Mostly I want the
discussion. If everyone feels that ebuilds is the best solution I'm
prepared to say I'm wrong. However it doesn't seem as anyone has
understood what I'm suggesting, yet. =)
-John
Joseph Booker
John Nilsson said:
> On Sat, 2004-05-22 at 00:40, Joseph Booker wrote:
>> ok, i totally get it:
>
> no.
eh, well i thought so
> no, I would like every single package to provide the information needed
> to be portable. Most useflags is probably of the --enable-<useflag>
> kind. Why maintain a separate list of configure options and package
> dependencies when the configure scripts already contain a list of
> options and easily could be extended to provide dependency information?
>
> Where to install files is probably hard to extend more, there already
> exists functionality for that.
well, this isn't always the case as many times ebuilds patch the packages
to support other things. An example is back when gaim .76 would never get
released since yahoo support was b0rked, and there was many security
problems. So, revisions of the ebuild patched gaim for the updates, while
the upstream devs released a secure version with a fix yahoo (at this
point i dont trust yahoo support anyways so im only taking their word its
fixed :P ), without that level of control over the packages, alot of users
would have been running unsecure versions of gaim for a while. This is
just one example btw.
> I would like portage to evolve into tools and patches so that the LFS
> experience would be somewhat gentooish. Gentoo the distribution is
> great. I just feel that portage could evolve outside Gentoo.
It seems more like your tring to make an extended ./configure script
evolve outside gentoo, not portage :P anways, what is portage if its not
ebuild-based? seems like a whole differant package managment system your
talking about creating, just with the same interface (emerge, etc)
> I'm not asking anyone to do anything, I'm suggesting. Mostly I want the
> discussion. If everyone feels that ebuilds is the best solution I'm
> prepared to say I'm wrong. However it doesn't seem as anyone has
> understood what I'm suggesting, yet. =)
I don't think many people here will say ebuilds are the best solution,
because people do come up with better ideas at times, but ebuilds have
worked thus far and atleast I havn't seen a better way (well, a portage
backend supporting 'plugins' for differant ways of storing ebuilds would
be interesing.............but no one has produced such code and i have
other things to work on).
Dare i say i once again think i sorta get what your saying? anyways,
getting support for this idea from upstreams devs will be hard as only
gentoo (and LFS) users are the only ones crazy enough to compile when
theres binarys avilable ;)
btw, next time you reply telling me what im mistaken, dont include me in
the CC: line, ill read in the mailing list, i woudln't mind, but after a
while its sorta annoying :P
John Nilsson
> John Nilsson said:
> > On Sat, 2004-05-22 at 00:40, Joseph Booker wrote:
> >> ok, i totally get it:
> >
> > no.
>
> eh, well i thought so
>
> > no, I would like every single package to provide the information needed
> > to be portable. Most useflags is probably of the --enable-<useflag>
> > kind. Why maintain a separate list of configure options and package
> > dependencies when the configure scripts already contain a list of
> > options and easily could be extended to provide dependency information?
> >
> > Where to install files is probably hard to extend more, there already
> > exists functionality for that.
>
> well, this isn't always the case as many times ebuilds patch the packages
> to support other things. An example is back when gaim .76 would never get
> released since yahoo support was b0rked, and there was many security
> problems. So, revisions of the ebuild patched gaim for the updates, while
> the upstream devs released a secure version with a fix yahoo (at this
> point i dont trust yahoo support anyways so im only taking their word its
> fixed :P ), without that level of control over the packages, alot of users
> would have been running unsecure versions of gaim for a while. This is
> just one example btw.
>
There are lots of ebuilds that provides a fair enough solution. I'm just
saying that there are even more that shouldn't be needed.
>
> > I would like portage to evolve into tools and patches so that the LFS
> > experience would be somewhat gentooish. Gentoo the distribution is
> > great. I just feel that portage could evolve outside Gentoo.
>
> It seems more like your tring to make an extended ./configure script
> evolve outside gentoo, not portage :P anways, what is portage if its not
> ebuild-based? seems like a whole differant package managment system your
> talking about creating, just with the same interface (emerge, etc)
I'm sort of slipped into the ./configure talk. I used that as an example
of tools that could(should?) be extended to make it easier to tailor the
installation policy.
The core idea is to move the dependency data from the ebuilds and put
that on the package developers. This would make it very easy to generate
ebuilds of the form:
<useflag>? dependency.
./configure --enable-<useflag>
make
make install
Even version tracking could be automated. Sourceforge + RSS should be an
interesting mix.
> > I'm not asking anyone to do anything, I'm suggesting. Mostly I want the
> > discussion. If everyone feels that ebuilds is the best solution I'm
> > prepared to say I'm wrong. However it doesn't seem as anyone has
> > understood what I'm suggesting, yet. =)
>
> I don't think many people here will say ebuilds are the best solution,
> because people do come up with better ideas at times, but ebuilds have
> worked thus far and atleast I havn't seen a better way (well, a portage
> backend supporting 'plugins' for differant ways of storing ebuilds would
> be interesing.............but no one has produced such code and i have
> other things to work on).
>
> Dare i say i once again think i sorta get what your saying? anyways,
> getting support for this idea from upstreams devs will be hard as only
> gentoo (and LFS) users are the only ones crazy enough to compile when
> theres binarys avilable ;)
I think that even other distributions would have use for formal
dependency statements in the source package.
> btw, next time you reply telling me what im mistaken, dont include me in
> the CC: line, ill read in the mailing list, i woudln't mind, but after a
> while its sorta annoying :P
done. Will start to use mutt one of these days =)
-John
Stuart Herbert
> no, I would like every single package to provide the information needed
> to be portable. Most useflags is probably of the --enable-<useflag>
> kind. Why maintain a separate list of configure options and package
> dependencies when the configure scripts already contain a list of
> options and easily could be extended to provide dependency information?
It should be possible to create a tool that would automatically make a
skeleton ebuild from a source tree that uses the autoconf toolset. You can
even auto-generate *some* of the dependencies too, by compiling the package
and using ldd. genrdepend, which I published last year, can do that part.
If every package came with metadata describing what it needs (which is what
you're really asking for I think) then we could do something with that. You
don't want it built into autoconf. There are still many packages out there
that don't use autoconf - and that can't ever ever ever use it.
> I would like portage to evolve into tools and patches so that the LFS
> experience would be somewhat gentooish. Gentoo the distribution is
> great. I just feel that portage could evolve outside Gentoo.
Having packages provide a metadata.xml file, listing their deps and optional
features, would help. Problem you'll find is that it won't be accurate
enough to be able to rely on automatically.
> I'm not asking anyone to do anything, I'm suggesting. Mostly I want the
> discussion. If everyone feels that ebuilds is the best solution I'm
> prepared to say I'm wrong. However it doesn't seem as anyone has
> understood what I'm suggesting, yet. =)
To be honest, you might have a lot more joy talking about this in one of the
FHS forums. But there again, they think RPM is a good thing, so maybe
not ;-)
John Nilsson
> John Nilsson said:
> > In the end I would like a system where I can install a tar.gz install it
> > and have it maintained/updated by portage without the need for an
> > ebuild. This would of course only work for packages that don't need
> > extra gentoo fitting.
>
> that seems like the way slackware works, except that tar.gz is installed
> using pkg-add or something like that............is that the kind of
> package managment you want?
Keep ebuilds for packages that needs them.
Use case:
#Download foo-1.2.tar.gz known as www.gnu.org/software/foo-1.2
tar xvfz foo-1.2.tar.gz
cd foo-1.2
./configure
#Configure fails because www.gnu.org/software/bar-2.3 is needed.
emerge bar
# emerge is successful
make
make install
now the system is in the same state as if I had run "emerge foo".
In the future "emerge -u foo" would first query the portage tree for an
ebuild, if none is found it will check if www.gnu.org/software/foo is a
later version, if it is it will download the latest sources and perform
the same steps as the initial install).
-John
John Nilsson
> On Saturday 22 May 2004 00:27, John Nilsson wrote:
> > no, I would like every single package to provide the information needed
> > to be portable. Most useflags is probably of the --enable-<useflag>
> > kind. Why maintain a separate list of configure options and package
> > dependencies when the configure scripts already contain a list of
> > options and easily could be extended to provide dependency information?
>
> It should be possible to create a tool that would automatically make a
> skeleton ebuild from a source tree that uses the autoconf toolset. You can
> even auto-generate *some* of the dependencies too, by compiling the package
> and using ldd. genrdepend, which I published last year, can do that part.
>
> If every package came with metadata describing what it needs (which is what
> you're really asking for I think) then we could do something with that. You
> don't want it built into autoconf. There are still many packages out there
> that don't use autoconf - and that can't ever ever ever use it.
We can drop the requirement that packages MUST have this. A SHOULD is
possible to get away with.
Build requirements is the only metadata I think of putting in the build
system though, and that is only because it would be easier to have
developers provide it if it is part of the normal syntax.
> > I would like portage to evolve into tools and patches so that the LFS
> > experience would be somewhat gentooish. Gentoo the distribution is
> > great. I just feel that portage could evolve outside Gentoo.
>
> Having packages provide a metadata.xml file, listing their deps and optional
> features, would help. Problem you'll find is that it won't be accurate
> enough to be able to rely on automatically.
If the data is important to the developers and/or most of the users it
would probably be accurate enough. So any implementation has to provide
value for more than Gentoo users.
Moving the maintainer responsibility upstream and having more than
gentooers use it does mean more eyes on the data.
> To be honest, you might have a lot more joy talking about this in one of the
> FHS forums. But there again, they think RPM is a good thing, so maybe
> not ;-)
I don't see what this has to do with the FHS. A w3c forum seems more
suitable. However the people most experience with dependency resolving
with regards to package types and stages, from development to
deployment, are the Gentoo developers.
-John
Allen Dale Parker
Hash: SHA1
Mr Nilsson:
As much as I enjoy reading your wonderful ideas in regards to
re-inventing the wheel and your complete and utter dissatisfaction with
current *NIX tools for building software, I respectfully request that
you drop this thread. It was entertaining about 3 days ago, when it
started. I don't think this is the place for this discussion to be
happening. Gentoo is only one small piece of the puzzle. If you can't
take a look at the big picture (in regards to autoconf/automake
supporting more than one Operating System, let alone more than one linux
distribution), please go do some research on UNIX-like operating
systems, or even better, take a look at gcc.gnu.org's list of supported
architectures: http://gcc.gnu.org/install/specific.html
My point is this: there were some very good things said in this thread.
At this time, it's a dead horse, so please stop beating it.
- --
Allen Parker
GPG KeyID: 35544083
GPG FP: E628 7310 DE68 321A 933A 5DD1 C831 005C 3554 4083
info...@irc.freenode.net #/tmp #gentoo-dev #gentoo-hardened
info...@irc.oftc.net #vserver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAsLj0yDEAXDVUQIMRAnd1AKCCtHcWPUdaUgOjMn4mq/MLAnliSACfdhR1
lfQY+8owKK9PZ46w6Pz9jOw=
=bZl4
Joseph Booker
John Nilsson said:
<snip>
im tring to reply to 3 posts at once, so about your other post considering
when a ./configure scripts fails on a dependacy, remember that the
./configure scripts are misleading, its sorta like a DEPEND, doesn't help
us in terms of the RDEPEND, PDEPEND, etc, and the optional stuff, we would
wind up having to have ebuilds for *alot* of packages, even ones that
follow your syste
> If the data is important to the developers and/or most of the users it
> would probably be accurate enough. So any implementation has to provide
> value for more than Gentoo users.
> Moving the maintainer responsibility upstream and having more than
> gentooers use it does mean more eyes on the data.
this data is already present to the developers and/or users, its called a
README. From an upstream maintainer points of view, it makes more sense to
relaeas rpms instead of ebuilds or your system. Either way it has to be
converted so some distro can use it
> I don't see what this has to do with the FHS. A w3c forum seems more
> suitable. However the people most experience with dependency resolving
> with regards to package types and stages, from development to
> deployment, are the Gentoo developers.
<quote> The World Wide Web Consortium (W3C) develops interoperable
technologies (specifications, guidelines, software, and tools) to lead the
Web to its full potential. </quote>
This has *nothing* to do with the w3c. The IEEE will make the standard of
ethernet that connects you to your broadband connection (if you got it),
other people define the TCP/IP protocal, others define the HTTP protocal,
the W3C define the langauage (xml,css,xhtml,svg,etc), the program choices
how to implent these thigns. if this was a webservice running off some
port, then you would use SOAP and such, if this was parsed web pages,
you'd use the (x)html standard, if this was raw data and its metadata,
you'd use soem form (standard or not) of xml.
but this is not stuff that gets transfered over the web. What you are
talking about is a software standard, weither the data is transfered
through the web doens't matter, its more somethign that you think should
be a standard for all *nix programs. that is far beyond the w3c's scope as
an internet standard organization. In all honestly i dont think it has
anything to do with FHS either, unless thats a bad typo for FSF, but im
not familar much with what the FHS does other then the basic stuff
Mr. Parker:
Surly you've been very over-enthusiatitic about something before. I think
its perferable to explain and try to convine why its not pratical then try
to tell him to give it up. Its not like hes disrupting any other
conversations or anything.
Karl Trygve Kalleberg
>
> I wonder if we can design an ebuild-lint tool to validate ebuilds
> automatically. It could work something like this:
>
> 2. ebuild-lint runs on it (out of cron, maybe)
> 3. If ebuild lint finds problems, the user is emailed with a laundry list of
> things to fix
> 4. When ebuild-lint finds no errors with the ebuild, then and only then is the
> ebuild brought to the attention of bug-wranglers, who would assign it to the
> proper herd.
I already did this two years ago. The project was called 'munchie'. It
did all kinds of sanity checks on the incoming ebuild's syntax, tried to
build it, and produced a lengthy report on the quality of the ebuild.
However, at the time, we were not able to integrate it with Bugzilla, don't
ask me why, I wasn't part of the infrastructure team even then, so it never
picked up.
However, if there is renewed interest in the project, I can bring it back to
life, as it still falls under my domain as a "portage tools"
maintainer/developer.
In the next version, I had planned a proper tinderbox, so we could do a lot
more compile-time/run-time checks on it.
Kind regards,
Karl T
Joseph Booker
Karl Trygve Kalleberg said:
> I already did this two years ago. The project was called 'munchie'. It
> did all kinds of sanity checks on the incoming ebuild's syntax, tried to
> build it, and produced a lengthy report on the quality of the ebuild.
is this anywhere in portage/gentoolkit/gentoolkit-dev/your
dev.gentoo.org/~ folder? that would be interesting for those learning and
devs looking at submitted ebuilds even if it isn't in bugzilla
I think it would be better if instead of using bugzilla, the ebuilds get
emailed as an attachment to add_me_t...@gentoo.org, which gets
handled by some python/perl script in cron that runs your tool, puts them
in order of those with the highest rating, and then emails that list every
day somewhere else (perhaps a read-only mailing lists so devs can see the
ebuilds requested for addition for the day and maybe decide to maintain
some from that list when they're bored?)
John Nilsson
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mr Nilsson:
>
> As much as I enjoy reading your wonderful ideas in regards to
> re-inventing the wheel and your complete and utter dissatisfaction with
> current *NIX tools for building software,
Actually I think they work impressively well.
> I respectfully request that
> you drop this thread. It was entertaining about 3 days ago, when it
> started.
Depending on it it's me or just the thread you dislike, you could filter
all mails from jo...@milsson.nu or just the thread, I will try to not
mention this issue in other threads.
> I don't think this is the place for this discussion to be
> happening. Gentoo is only one small piece of the puzzle.
Actually I think Gentoo is a large part of the puzzle, possibly the most
extensive research in the issue.
> If you can't
> take a look at the big picture (in regards to autoconf/automake
> supporting more than one Operating System, let alone more than one linux
> distribution), please go do some research on UNIX-like operating
> systems, or even better, take a look at gcc.gnu.org's list of supported
> architectures: http://gcc.gnu.org/install/specific.html
This is the part I seem to not be able to communicate. In this case I
think it is you who can't see how formal system integration hints would
fit in the big picture.
I just invented that description, it seems like a correct description:
"Formal system integration hints"...
> My point is this: there were some very good things said in this thread.
> At this time, it's a dead horse, so please stop beating it.
In what way is it dead?
-John
John Nilsson
> John Nilsson said:
> <snip>
>
> im tring to reply to 3 posts at once, so about your other post considering
> when a ./configure scripts fails on a dependacy, remember that the
> ./configure scripts are misleading, its sorta like a DEPEND, doesn't help
> us in terms of the RDEPEND, PDEPEND, etc, and the optional stuff, we would
> wind up having to have ebuilds for *alot* of packages, even ones that
> follow your syste
This is why gentoo-dev is the place for this discussion. And also why I
mentioned w3c. Stuart mentioned ldd to solve part of the issue. For the
moment I have no idea on how RDEPEND could be retrieved from some data
in a reliable maner. You would still have to rely on some maintainer.
But a scheme where the package maintainer was responsible for updating
the data and received update requests from a large user base might be
reliable enough.
> > If the data is important to the developers and/or most of the users it
> > would probably be accurate enough. So any implementation has to provide
> > value for more than Gentoo users.
> > Moving the maintainer responsibility upstream and having more than
> > gentooers use it does mean more eyes on the data.
>
> this data is already present to the developers and/or users, its called a
> README. From an upstream maintainer points of view, it makes more sense to
> relaeas rpms instead of ebuilds or your system. Either way it has to be
> converted so some distro can use it
... that's my point... If the information in README where machine
readable the converting would be easier. They shouldn't have to provide
a .rpm, a .deb and a .msi the tar.gz + metadata should be enough.
> > I don't see what this has to do with the FHS. A w3c forum seems more
> > suitable. However the people most experience with dependency resolving
> > with regards to package types and stages, from development to
> > deployment, are the Gentoo developers.
>
> <quote> The World Wide Web Consortium (W3C) develops interoperable
> technologies (specifications, guidelines, software, and tools) to lead the
> Web to its full potential. </quote>
>
> This has *nothing* to do with the w3c. The IEEE will make the standard of
> ethernet that connects you to your broadband connection (if you got it),
> other people define the TCP/IP protocal, others define the HTTP protocal,
> the W3C define the langauage (xml,css,xhtml,svg,etc), the program choices
> how to implent these thigns. if this was a webservice running off some
> port, then you would use SOAP and such, if this was parsed web pages,
> you'd use the (x)html standard, if this was raw data and its metadata,
> you'd use soem form (standard or not) of xml.
>
> but this is not stuff that gets transfered over the web. What you are
> talking about is a software standard, weither the data is transfered
> through the web doens't matter, its more somethign that you think should
> be a standard for all *nix programs. that is far beyond the w3c's scope as
> an internet standard organization. In all honestly i dont think it has
> anything to do with FHS either, unless thats a bad typo for FSF, but im
> not familar much with what the FHS does other then the basic stuff
I'm talking about a lot of components, probably why I'm having such a
hard time communicating it. The central and important part however
revolves around an interoperable way of communicating system integration
hints(TM).
This whole system pretty much depends on the web. I like to think about
the web as a web of information, not as the infrastructure to transfer
the information. My reference to w3c were ment as a contrast to fhs
though.
I still believe that RDF is the perfect fit for communicating this
information.
> Mr. Parker:
>
> Surly you've been very over-enthusiatitic about something before. I think
> its perferable to explain and try to convine why its not pratical then try
> to tell him to give it up. Its not like hes disrupting any other
> conversations or anything.
My sentiments exactly =)
-John
Karl Trygve Kalleberg
>
> Karl Trygve Kalleberg said:
> > I already did this two years ago. The project was called 'munchie'. It
> > did all kinds of sanity checks on the incoming ebuild's syntax, tried to
> > build it, and produced a lengthy report on the quality of the ebuild.
>
> is this anywhere in portage/gentoolkit/gentoolkit-dev/your
> dev.gentoo.org/~ folder? that would be interesting for those learning and
> devs looking at submitted ebuilds even if it isn't in bugzilla
Currently not. I'll spend some time digging it out from my backups. The only
public records of it that have survived are, strangely enough, at the zynot
pages(!):
http://wiki.zynot.org/zynot/moin.cgi/ZynotZyrvices_2fProposedServices
> I think it would be better if instead of using bugzilla, the ebuilds get
> emailed as an attachment to add_me_t...@gentoo.org, which gets
> handled by some python/perl script in cron that runs your tool, puts them
> in order of those with the highest rating, and then emails that list every
> day somewhere else (perhaps a read-only mailing lists so devs can see the
> ebuilds requested for addition for the day and maybe decide to maintain
> some from that list when they're bored?)
The munchie-suite has a command line user tool which does exactly this. In
fact, the user tool will run as many tests it can locally on the user's
machine first, so that the user gets very early warning/error reports. No
sense in submitting something that is provably in violation of development
policies.
I'll put some docs out, and the old script, tomorrow.
Kind regards,
Karl T
Marius Mauch
> ... that's my point... If the information in README where machine
> readable the converting would be easier. They shouldn't have to
> provide a .rpm, a .deb and a .msi the tar.gz + metadata should be
> enough.
Why don't you go ahead and tell everyone to use the same package names
and versioning schemes for all packages, as that would be the first
requirement before your idea could even be considered by upstream.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
Joseph Booker
John Nilsson said:
> This is why gentoo-dev is the place for this discussion. And also why I
> mentioned w3c. Stuart mentioned ldd to solve part of the issue. For the
> moment I have no idea on how RDEPEND could be retrieved from some data
> in a reliable maner. You would still have to rely on some maintainer.
> But a scheme where the package maintainer was responsible for updating
> the data and received update requests from a large user base might be
> reliable enough.
Most (if not all distros) test their packages to be sure they work as
expected......sometimes the upstream devs aint detailed or something, and
thats *really* bad for stuff like gcc/binutils/glibc or python if they
forget to mention even something small
It might be interesting to use ROOT=/normal_system emerge -ve system && cp
-r /normal_system /nano_system && ROOT=/nano_system emerge -v nano, chroot
in, and see if nano runs to test its RDEPEND. Faketoo would actually
probly be better then emerge -vpe system though.
> .. that's my point... If the information in README where machine
> readable the converting would be easier. They shouldn't have to provide
> a .rpm, a .deb and a .msi the tar.gz + metadata should be enough.
Some packages only provide tarballs and the docs, and they leave it to the
distros to make the packages. They dont bother with which distro is best
or which package managment system is best or anything like that. And the
way you have been descibing it makes it sound like it would make all other
packagment unnessary or based on this......im sure the inventers of rpm or
dpkg thought the same, but atleast they were tring to fix specific
problems
> I'm talking about a lot of components, probably why I'm having such a
> hard time communicating it. The central and important part however
> revolves around an interoperable way of communicating system integration
> hints(TM).
it does not seem like a lot of components if its just an RDF file :P
>
>> Mr. Parker:
>>
>> Surly you've been very over-enthusiatitic about something before. I
>> think
>> its perferable to explain and try to convine why its not pratical then
>> try
>> to tell him to give it up. Its not like hes disrupting any other
>> conversations or anything.
>
> My sentiments exactly =)
why don't we talk over irc? Theres bigger chancing of changing each others
mind in real time, email me off the list if your interested
i just saw genome's message.......another point is that package can be
called differant things in differant distros, esp dependance of i18n
versions, the only people who could pull off such a thing would probly be
if kde and gnome and FSF got together and decided on provided this kind of
metadata......no offense, but i dont think you got that kind of influence
John Nilsson
> Why don't you go ahead and tell everyone to use the same package names
> and versioning schemes for all packages, as that would be the first
> requirement before your idea could even be considered by upstream.
I would think that it'd be a lot easier to convince them if they can
keep their scheme of choice...
-John
Duncan
<33555.68.78.45.146....@webmail.neoturbine.net>, excerpted
below, on Sun, 23 May 2004 18:34:33 -0500:
> i just saw genome's message.......another point is that package can be
> called differant things in differant distros, esp dependance of i18n
> versions, the only people who could pull off such a thing would probly be
> if kde and gnome and FSF got together and decided on provided this kind of
> metadata......no offense, but i dont think you got that kind of influence
Actually, that's what the freedesktop.org and lsb standards are doing, in
their respective areas. If you are really interested in doing something
upstream farther than Gentoo, and making it pretty much universal, I'd get
involved in one of those organizations. (In this case, lsb would be the
place to go, as freedesktop is more GUI standards, not core system
standards irrespective of GUI or CLI choice.)
--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin
--
gento...@gentoo.org mailing list
John Nilsson
> Actually, that's what the freedesktop.org and lsb standards are doing, in
> their respective areas. If you are really interested in doing something
> upstream farther than Gentoo, and making it pretty much universal, I'd get
> involved in one of those organizations. (In this case, lsb would be the
> place to go, as freedesktop is more GUI standards, not core system
> standards irrespective of GUI or CLI choice.)
In due time. The idea is still rather immature and the people most
experienced with the implementation issues are gentoo developers. If it
is this hard to convince gentooers about the technical merits, imagine
the agony making a case to a more independent group.
As Mr. Parker so elegantly suggested, I will end this thread. I'll
return when I have a more concrete suggestion and the parts concerning
gentoo isolated. In the mean time I'll try to be available on irc if
anyone feels to flame me.
-John
Paul de Vrieze
Hash: SHA1
On Monday 24 May 2004 06:59, John Nilsson wrote:
> On Mon, 2004-05-24 at 06:11, Duncan wrote:
> > Actually, that's what the freedesktop.org and lsb standards are
> > doing, in their respective areas. If you are really interested in
> > doing something upstream farther than Gentoo, and making it pretty
> > much universal, I'd get involved in one of those organizations. (In
> > this case, lsb would be the place to go, as freedesktop is more GUI
> > standards, not core system standards irrespective of GUI or CLI
> > choice.)
>
> In due time. The idea is still rather immature and the people most
> experienced with the implementation issues are gentoo developers. If
> it is this hard to convince gentooers about the technical merits,
> imagine the agony making a case to a more independent group.
The problem is not only in technical merits. The technical issues are big
but I'm quite sure it is possible to overcome them. However the biggest
impediment to this is organization. How are you going to make all those
hundreds of thousands of developers all follow the same direction. How
are you going to ensure that what they write is correct. It will still
be necessary to patch upstream packages as some will be broken.
Paul
- --
Paul de Vrieze
Gentoo Developer
Mail: pau...@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD4DBQFAsbCcbKx5DBjWFdsRAnCrAJd8N7/VqZnvp2SXqoiQ2C5papflAJwJTjRH
KHpWGLn8/z1qHa8eGXyTfg==
=mUKP
Jean Jordaan
The fix is easy and hard. Easy: get a dedicated ebuild QA team
with a n-day turnaround time. Hard: who's gonna do that? If
some bigcorp is making money off "Enterprise Gentoo" then they
could sponsor a team. But building dependence on such
sponsorship into Gentoo infrastructure is a bad thing.
In the future of this thread ;>, someone will say:
> so we need 345 devs plus people to work on portage,
Perhaps it would be worthwhile to have a (Graphviz-generated :)
organisation tree for Gentoo, with flags for roles that lack
the required manpower, and recruitment drives to get volunteers
and sponsors ..
Hmm, this sounds like a social-engineering project next to
Gentoo. I know there are people who make their money just by
finding tax-deductable things for corporates to donate to ..
--
Jean Jordaan
http://www.upfrontsystems.co.za
/training <-- Zope/Plone training!
/training/af <-- Nie af nie, Afrikaans.
--
gento...@gentoo.org mailing list