Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Harald van Dijk
On Fri, Mar 16, 2007 at 09:24:33PM -0400, Mike Frysinger wrote:
 On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
  Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
  milestone releases. These are pretty stable and usable since milestone 7
  of netbeans 6.0 with many new features that make sense to use the
  milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
  though I was assured by mkt guy from Sun it is not yet alpha quality. It
  would be fair to the upstream and to users to not use _alpha because it
  is not alpha but there's no appropriate choice available.
 
 i would use _p# over _alpha#

6.0_p7 is considered a higher version than 6.0, right? That will probably
cause problems in the future. _pre# may be a good choice, though.


pgpAEes51I0pb.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ilya A. Volynets-Evenbakh
Rather then analyze the proposed solution, I'd like to
question the problem itself. Do we really want to provide
all the different intermediate development sort of releases
in our tree?

William L. Thomson Jr. wrote:
 After reviewing 

 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules


 I still seem to be having to finagle version names for some packages. At
 the moment it would be nice if we also had the following suffixes
 available

 _dev
 Apache upstream, specifically Tomcat/mod_jk tends to do developer
 snapshots that they then host out of developer space. People do fetch
 bins and source from there for testing. It's kinda pre-release, so I
 have been using _pre where I would use _dev, but _pre does not make much
 sense.

 _build
 Other packages seem to do constant builds (weekly) of the same version.
 For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39.
 So would be nice to be able to do like glassfish-servlet-api-2_build39

 _snapshot
 This one is kinda universal in it's name/implication. Would be for any
 sort of upstream snapshot release, that might not be versioned as such.
 Short of the name snapshot being some where.

 The above would then follow the rest of the normal schema, where in they
 could still be suffixed by a number, or not.

 Hierarchy would be the following

 snapshot - dev - build - alpha - beta 

 Or at least that's my thoughts on it. Time for others thoughts, much
 less those that will make it so. Not expecting it to get done or be
 available any time soon. Would be suffice if they were just accepted and
 planned for inclusion at some point.

   

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 01:08 -0700, Ilya A. Volynets-Evenbakh wrote:
 Rather then analyze the proposed solution, I'd like to
 question the problem itself. Do we really want to provide
 all the different intermediate development sort of releases
 in our tree?

That came up in the link I provided in another post.
http://marc.info/?l=tomcat-devm=117251925901310w=2

IMHO I think it should be up to the package maintainer how close they
want to follow upstream. With regard to development, progress, testing,
qa, feedback. I think it's a very good thing, since it allows things to
be caught before actual releases, during development.

I know when I am developing stuff, it's way easier to address during the
process rather than after the fact.

But if there are any policies or etc. I surely do not want to be
breaking them. Also this is not broken or really experimental stuff. If
it was I would either p.mask, or put in an overlay.

Although I feel things tend to get the greatest exposure and chance of
user testing and feedback, if it's in tree.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to
http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
it seems to me the versioning is focused on package stability life
cycle. In netbeans case it is _prealpha and definitely not stable
patched release. So _alpha is the closest one to current netbeans 6.0
life cycle phase, though not accurate.

- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team


Mike Frysinger napsal(a):
 On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
 Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
 milestone releases. These are pretty stable and usable since milestone 7
 of netbeans 6.0 with many new features that make sense to use the
 milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
 though I was assured by mkt guy from Sun it is not yet alpha quality. It
 would be fair to the upstream and to users to not use _alpha because it
 is not alpha but there's no appropriate choice available.
 
 i would use _p# over _alpha#
 -mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+6oPRSzWCmqu+0YRAhPAAJ99Et9Uwk/JrpRPkukABgrc3CdLfQCghrm+
noRpxMDQvlxrlLhFUdqb088=
=gC2k
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ilya A. Volynets-Evenbakh
William L. Thomson Jr. wrote:
 IMHO I think it should be up to the package maintainer how close they
 want to follow upstream. With regard to development, progress, testing,
 qa, feedback. I think it's a very good thing, since it allows things to
 be caught before actual releases, during development.

 I know when I am developing stuff, it's way easier to address during the
 process rather than after the fact.

 But if there are any policies or etc. I surely do not want to be
 breaking them. Also this is not broken or really experimental stuff. If
 it was I would either p.mask, or put in an overlay.

 Although I feel things tend to get the greatest exposure and chance of
 user testing and feedback, if it's in tree
There is a bit of contradiction in what you said there.
Either the package is well tested, and should go into the tree, first
with ~arch keywords, and then eventually with arch keywords, or
it is experimental, and as such has to be outside of our main tree.

Thus you can either want to test stuff by giving it more exposure,
which implies the stuff is experimental, or you have stable stuff,
but then you shouldn't be talking about the development cycle of the
said software.



-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Jakub Moc
Miroslav Šulc (fordfrog) napsal(a):
 According to
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 it seems to me the versioning is focused on package stability life
 cycle. In netbeans case it is _prealpha and definitely not stable
 patched release. So _alpha is the closest one to current netbeans 6.0
 life cycle phase, though not accurate.

Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
portage; dunno how does that fit the netbeans upstream scheme, though.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Marijn Schouten (hkBst)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
 On Fri, 16 Mar 2007 18:25:17 -0400
 William L. Thomson Jr. [EMAIL PROTECTED] wrote:
 
 Hierarchy would be the following

 snapshot - dev - build - alpha - beta 
 
 And that's where the problems start. As you said yourself _snapshot is
 something universal so it doesn't really fit anywhere in the chain.
 Similar for _build, it usually runs parallel to normal versioning (a
 release also has a build number). Don't know about _dev, never seen a
 package where that would be useful myself.
 And as has been said, there are compability issues. At best older
 portage versions would ignore ebuilds using these new suffixes
 resulting in confused users, worst case stuff starts breaking.
 If you want to pursue this you should get some numbers of how many
 packages could actually make use of these new features, it simply isn't
 worth thinking about it for just a handful of packages.
 
 Marius

One thing we could do would be to separate hierarchy from version naming. That 
way we can allow
arbitrary version names and also smoothly traverse version scheme changes such 
that break hierarchy.
This would prevent cases like currently with rosegarden (~)1.2.4 (~)1.4.0 
4.1.0-r1 4.1.0-r2, where
it really should be 4.1.0-r1 4.1.0-r2 (~)1.2.4 (~)1.4.0.

We could also add an internal version which would be compared first and only if 
it is equal for
packages would the version in the ebuild name be used for ordering.

Just throwing some ideas out there,

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+7jup/VmCx0OL2wRAhszAJwNo29AEj6rOSlimu+sbi8OwUPeKgCePo2g
2g1sI/Tk+ZYnRQ0j8b7d+44=
=SdRi
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] gs use flag local - global

2007-03-17 Thread Steve Dibb

Any objections to globalizing the 'gs' use flag on support for ghostscript?

$ euse -i gs
global use flags (searching: gs)

no matching entries found

local use flags (searching: gs)

[-] gs (app-office/rabbit):
Ghostscript support

[-] gs (media-gfx/graphicsmagick):
enable ghostscript support

[-] gs (media-gfx/imagemagick):
enable ghostscript support

[-] gs (media-libs/urt):
Add support for postscript

thanks

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



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jakub Moc napsal(a):
 Miroslav Šulc (fordfrog) napsal(a):
 According to
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 it seems to me the versioning is focused on package stability life
 cycle. In netbeans case it is _prealpha and definitely not stable
 patched release. So _alpha is the closest one to current netbeans 6.0
 life cycle phase, though not accurate.
 
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.


Where does this come from? There is nothing about it in devmanual. And
is '_alpha  _alpha_pre' true of false? Anyway I'd rather preffer
_prealpha than _alpha_pre :-)


- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+9m2RSzWCmqu+0YRAt+3AJ9RcqsIgCzlJCygKyRrqEGZY6lmogCffLWl
ZdCUglDhgQAiBaop7G1dXM4=
=14Rp
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gs use flag local - global

2007-03-17 Thread Piotr Jaroszyński
On Saturday 17 of March 2007 12:28:42 Steve Dibb wrote:
 Any objections to globalizing the 'gs' use flag on support for ghostscript?
I have heard about the magic limit of 5, but whatever...

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ciaran McCreesh
On Sat, 17 Mar 2007 10:46:22 +0100 Marijn Schouten (hkBst)
[EMAIL PROTECTED] wrote:
 One thing we could do would be to separate hierarchy from version
 naming.

That was one of Zynot's goals. You might want to investigate how they
ended up solving it.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/



signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, Jakub Moc wrote:
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.

The additional postfix is reserved exclusively for user local ebuilds, not for 
the ones provided by us.


Carsten


pgpGn5BppX9RK.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Petteri Räty
Carsten Lohrke kirjoitti:
 On Samstag, 17. März 2007, Jakub Moc wrote:
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.
 
 The additional postfix is reserved exclusively for user local ebuilds, not 
 for 
 the ones provided by us.
 
 
 Carsten

It's already used by alsa-driver.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
This is a valid argument for a single postfix with a lower order than alpha, 
but not a reason to add everything what's out there. I don't see the need to 
match upstream's versioning bit by bit. Honestly said I've never understood 
why our order is alpha, beta, pre and not pre, alpha, beta, which would fix 
the issue and match more closely what happens in the tree. Changing this 
might break the one or the other dependency, though. Last but not least to 
add that I consider adding snapshots of regular releasing upstream projects 
as a waste of ressources.


Carsten


pgp1NJc2BVkzW.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, William L. Thomson Jr. wrote:
 IMHO I think it should be up to the package maintainer how close they
 want to follow upstream. With regard to development, progress, testing,
 qa, feedback. I think it's a very good thing, since it allows things to
 be caught before actual releases, during development.

Doing this locally or in some development overlay is fine, but polluting the 
tree with every single development build is a bad idea, imho.


Carsten


pgp1uJsUyuQ6N.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
 Well that's the problem. When I use say _pre instead of _dev it gives
 off the wrong impression to users judging package by it's name. Since
 it's not a pre-release. A user may go upstream looking for some sort of
 pre-release. Which they won't find.

We have stable, testing and masked ebuilds. Nothing else the user should care 
about. If he does, he can more closely looking what's up himself.


Carsten


pgpxB7QSMPAm9.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Jakub Moc
Carsten Lohrke napsal(a):
 The additional postfix is reserved exclusively for user local ebuilds, not 
 for 
 the ones provided by us.

Such as media-sound/alsa-driver-1.0.14_rc2_p3234 ? :)

Anyway, if you have better ideas, move them to Bug 166522; multiple
suffixes are definitely needed, just should be restricted to sane combos.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ciaran McCreesh
On Sat, 17 Mar 2007 15:06:07 +0200 Petteri Räty [EMAIL PROTECTED]
wrote:
 Carsten Lohrke kirjoitti:
  On Samstag, 17. März 2007, Jakub Moc wrote:
  Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and
  honored by portage; dunno how does that fit the netbeans upstream
  scheme, though.
  
  The additional postfix is reserved exclusively for user local
  ebuilds, not for the ones provided by us.
  
  
  Carsten
 
 It's already used by alsa-driver.

And there's bug 166522 open about it. Some people consider Portage's
acceptance of alsa-driver-like versions to be a bug.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/



signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, Petteri Räty wrote:
 It's already used by alsa-driver.

Then either me or the one doing so missed something on the discussion, why it 
was requested in the first place. Something to clarify in our ebuild policy.


Carsten


pgpUkMku2iZHo.pgp
Description: PGP signature


Re: [gentoo-dev] gs use flag local - global

2007-03-17 Thread Drake Wyrm
Steve Dibb [EMAIL PROTECTED] wrote:
 Any objections to globalizing the 'gs' use flag on support for ghostscript?
snip
 [-] gs (app-office/rabbit):
 Ghostscript support
 
 [-] gs (media-gfx/graphicsmagick):
 enable ghostscript support
 
 [-] gs (media-gfx/imagemagick):
 enable ghostscript support
 
 [-] gs (media-libs/urt):
 Add support for postscript

If you're feeling ambitious, it might be more appropriate to change that
use flag to ``ps: Add support for postscript'' so that it describes the
functionality rather than the package providing that functionality.

Also, there is another package (www-apps/knowledgetree) that uses the
`ps' use flag, so that could be included to make the ``magic five''
mentioned by peper.

-- 
mount /dev/wyrm /mnt/bed ; sleep 28800


pgpwRqIyzjA4M.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 02:20 -0700, Ilya A. Volynets-Evenbakh wrote:

 There is a bit of contradiction in what you said there.
 Either the package is well tested, and should go into the tree, first
 with ~arch keywords, and then eventually with arch keywords, or
 it is experimental, and as such has to be outside of our main tree.

Well take Tomcat 6.0.x for example. I followed it's development and did
many bumps over 3-4 months or so, from 6.0.2 to 6.0.10. Several in
between went alpha, a few betas. They wanted to do several releases, but
kept finding bugs or etc. That delayed a the release and caused them to
do another bump on package version. Which after all that will likely be
some time before they release  6.0.10 :)

Now sure if any Gentoo users contributed in that process. But at the
same time, I would like to give those using this stuff as much notice
as possible. So they can test in their own envs. Keep in mind most of
this is server stuff. Most will want to test for some time before it
gets deployed to a production env.

From watching user comments on the developers list. Many are still
running Tomcat 5.0.28 since there were issues in 5.5.x that were not
resolved for years till 5.5.23 was released a few weeks ago.

WRT Gentoo, part of the idea behind following upstream that closely.
Allows us to hopefully identify any issues ahead of time. So when
upstream does an official release. We can bump package, wait 30 days and
stabilize. Without that being dragged out due to bug discoveries, and
waiting for upstream to react after the fact.

Tomcat did go unmaintained for about a year or so. Also trying to make
up for that. Letting people know it will be active maintained. Which
hopefully will encourage them to use Gentoo for their Java Server
platform or etc.

 Thus you can either want to test stuff by giving it more exposure,
 which implies the stuff is experimental, or you have stable stuff,
 but then you shouldn't be talking about the development cycle of the
 said software.

Any version of say Tomcat or mod_jk, I have put into tree before
official release has been stable for me. Idea is to find out if it's
stable for others as well. So while it's official status cause it to
fall into experimental category. Most have no issues, and bugs do not
tend to be very obvious or commonly run into.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 14:13 +0100, Carsten Lohrke wrote:
 On Samstag, 17. März 2007, William L. Thomson Jr. wrote:
  IMHO I think it should be up to the package maintainer how close they
  want to follow upstream. With regard to development, progress, testing,
  qa, feedback. I think it's a very good thing, since it allows things to
  be caught before actual releases, during development.
 
 Doing this locally or in some development overlay is fine, but polluting the 
 tree with every single development build is a bad idea, imho.

Well at best I might have 2 development versions in tree. But most
times it's just one, and I will remove older versions during any bump.
So hardly any polluting going on. Definitely no worse than what occurred
when the package was going unmaintained :)

Also in server envs, it seems most prefer not to use overlays. From my
own experiences, I can't blame them much. Even for testing servers. They
will usually divert and wait to test till it hits tree :(

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] gs use flag local - global

2007-03-17 Thread Michael Krelin

If you're feeling ambitious, it might be more appropriate to change that
use flag to ``ps: Add support for postscript'' so that it describes the
functionality rather than the package providing that functionality.


Isn't less ambiguous 'postscript' even better?

Love,
H
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Marius Mauch
On Sat, 17 Mar 2007 14:01:45 +0100
Carsten Lohrke [EMAIL PROTECTED] wrote:

 On Samstag, 17. März 2007, Jakub Moc wrote:
  Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
  portage; dunno how does that fit the netbeans upstream scheme, though.
 
 The additional postfix is reserved exclusively for user local ebuilds, not 
 for 
 the ones provided by us.

No, you're confusing it with a different idea that deals with extending
the revision part (that isn't implemented yet).

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



Re: [gentoo-dev] gs use flag local - global

2007-03-17 Thread Steve Dibb

Michael Krelin wrote:

If you're feeling ambitious, it might be more appropriate to change that
use flag to ``ps: Add support for postscript'' so that it describes the
functionality rather than the package providing that functionality.


Isn't less ambiguous 'postscript' even better?


I was thinking the same thing.  Why don't we just change the use flag as well?

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



Re: [gentoo-dev] A User's View of the Code of Conduct

2007-03-17 Thread M. Edward (Ed) Borasky

Larry Lines wrote:

The network analysts at
one of my jobs actually make the new people install Gentoo on a box just
for the experience.
  
Unless there's a compelling business argument for this practice, I 
consider it an abuse of authority. Does this practice increase revenues 
or decrease costs for the business in question?



--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: gs use flag local - global

2007-03-17 Thread Steve Long
Piotr Jaroszy?ski wrote:
 I have heard about the magic limit of 5, but whatever...
 
Is there a *technical* objection then to server?
global use flags (searching: server)

no matching entries found

local use flags (searching: server)

[-] server (dev-ruby/rubygems):
rubygems server support

[-] server (dev-util/cvs):
Enable server support

[-] server (games-strategy/wesnoth):
Enable compilation of server

[-] server (net-misc/tightvnc):
Build vncserver. Allows us to only build server on one machine if set, build
only viewer otherwise.

[-] server (net-misc/vnc):
Build VNC server

[-] server (sci-astronomy/setiathome):
Enable compilation of server

[-] server (sci-mathematics/yacas):
Build the network server version.

[-] server (sci-misc/boinc):
Enable compilation of server

[-] server (sys-cluster/torque):
Enable compilation of server

Or is it a fear that other maintainers will start to use it? And what is the
consequence that gives rise to that fear?


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gs use flag local - global

2007-03-17 Thread Doug Goldstein
Steve Dibb wrote:
 Michael Krelin wrote:
 If you're feeling ambitious, it might be more appropriate to change that
 use flag to ``ps: Add support for postscript'' so that it describes the
 functionality rather than the package providing that functionality.

 Isn't less ambiguous 'postscript' even better?
 
 I was thinking the same thing.  Why don't we just change the use flag as
 well?
 
 Steve

I like 'postscript' because it's much more descriptive. 'ps' is vague as
is 'gs'.


-- 
Doug Goldstein [EMAIL PROTECTED]
http://dev.gentoo.org/~cardoe/



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: A User's View of the Code of Conduct

2007-03-17 Thread Steve Long
M. Edward (Ed) Borasky wrote:
 Larry Lines wrote:
 The network analysts at
 one of my jobs actually make the new people install Gentoo on a box just
 for the experience.
   
 Unless there's a compelling business argument for this practice, I
 consider it an abuse of authority. Does this practice increase revenues
 or decrease costs for the business in question?
 
I'd imagine both ;)


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: A User's View of the Code of Conduct

2007-03-17 Thread Dale
Steve Long wrote:
 M. Edward (Ed) Borasky wrote:
   
 Larry Lines wrote:
 
 The network analysts at
 one of my jobs actually make the new people install Gentoo on a box just
 for the experience.
   
   
 Unless there's a compelling business argument for this practice, I
 consider it an abuse of authority. Does this practice increase revenues
 or decrease costs for the business in question?

 
 I'd imagine both ;)


   

And you will learn a LOT about Linux and the computer you are working
on.  That is really true if you compile your own kernel. 

I think it is a pretty good idea.

Dale

:-)  :-)  :-)

-- 
www.myspace.com/-remove-me-dalek1967



Re: [gentoo-dev] Gentoo's problems

2007-03-17 Thread M. Edward (Ed) Borasky

Ciaran McCreesh wrote:

I think you're massively underestimating the requirements of the
average user, what with the tree as complex as it is these days. Most
users now:

* Have to use external repositories
* Have to handle at least some keywording overrides themselves
* Have to have some way of managing huge metapackages
* Have closer to a thousand than a hundred installed packages
* Aren't involved in development work
* Expect their systems to work

These are very different use cases than those for which Portage was
designed.
  
Well ... am I an average Gentoo user? I'm certainly an *experienced* 
one. I've got a modus operandi that works for me and what I want to do 
with Gentoo, which is essentially run cutting edge but usable (by me) 
scientific and algorithmic composition and synthesis workstations. So 
what I have on my systems is mostly ~x86, lots of local USE flags 
enabled in /etc/make.conf, a package.use that turns on doc on things 
when I want the documentation installed, and a fair number of other 
things built from upstream source. So


1. I use external repositories, mostly for things that aren't in 
Portage. In almost all cases I download them as source directly from 
their home page.
2. I'm not sure what keywording over-rides are. I do occasionally put 
something in package.mask that refuses to compile, but in general 
everything on my boxes is ~x86 and I've never gotten a system so broken 
that I couldn't fix it without a re-install.
3. I'm not sure what managing huge metapackages means ... I don't 
recall having to do that.

4. $ esearch -FInv ^|grep ^\*|wc -l
540
$

Yeah, on a log scale, that's closer to 1000 than it is to 100. :)
5. I'm not really involved in much development work except a lot of 
testing. The projects I'm building on my own are mostly very simple 
things. But I certainly wouldn't say I'm not a developer.
6. I expect my systems to break and I expect to be able to unbreak them 
myself when they do. For the most part, they would work for someone who 
just wanted to surf the web, send and receive email and edit documents 
in AbiWord or OpenOffice.org.


So ... am I an average Gentoo user?


--
gentoo-dev@gentoo.org mailing list