[gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Hello there!


Among other information the Gentoo page at DistroWatch [1] displays a
table on about 200 selected packages [2] and how up to date Gentoo is
per package.  I assume that DistroWatch is still one of the first places
people go to get a feeling for a Distro they heard about, besides
Wikpedia and ${distro}.org.

The freshness of these 200 packages have influence on how people
perceive Gentoo on DistroWatch.  While the tree as a whole is what we
should keep as up to date as possible keeping these 200 packages (list
further down) up to date can therefore be of particular importance.

From a quick look at the table these packages seem to need extra care in
Gentoo:

  cups (1.4.0)     1.3.11  <-- latest in Gentoo unstable/testing
  koffice (2.0.2)  1.6.3
  mysql (5.1.38)   5.0.84
  perl (5.10.1)    5.8.8
  php (5.3.0)      5.2.10
  samba (3.4.1)    3.3.7


Packages not found in Gentoo that DistroWatch monitors across discros are:

  apt
  synaptic
    .. Debian stuff, that Gentoo does not have packaged

  apache
  mod_ssl
    .. Apache 1.x seems gone from Gentoo (I suppose security)

  openjdk
    .. Not packaged in Gentoo, no idea why

  checkinstall
  Miro
    .. Not in official tree (yet?), available through an Overlay

  xmms
    .. Removed for security reasons, available through an Overlay

Maybe we should move Miro to the main tree?


Since today DistroWatch's sources on tree freshness are [3] and [4] as
they provide more accurate data than previously used sources do.

What is the process to migrate the generating script over to Gentoo
infrastructure?

See you,



Sebastian


[1] http://distrowatch.com/table.php?distribution=gentoo
[2] http://distrowatch.com/packages.php
[3] http://www.hartwork.org/public/distrowatch_gentoo_x86_latest_stable.txt
[4]
http://www.hartwork.org/public/distrowatch_gentoo_x86_latest_unstable.txt


List of all Gentoo packages currently monitored
===============================================
abiword app-office/abiword
AfterStep x11-wm/afterstep
alpine mail-client/alpine
alsa-lib media-libs/alsa-lib
amarok media-sound/amarok
apache-tomcat www-servers/tomcat
ati-driver x11-drivers/ati-drivers
audacity media-sound/audacity
autoconf sys-devel/autoconf
automake sys-devel/automake
avidemux media-video/avidemux
banshee media-sound/banshee
bash app-shells/bash
bind net-dns/bind
binutils sys-devel/binutils
bison sys-devel/bison
blender media-gfx/blender
bluefish app-editors/bluefish
bzip2 app-arch/bzip2
cdrkit app-cdr/cdrkit
cinelerra media-video/cinelerra
compiz x11-wm/compiz
coreutils sys-apps/coreutils
cups net-print/cups
curl net-misc/curl
cvs dev-util/cvs
db sys-libs/db
DeviceKit sys-apps/devicekit
dhcp net-misc/dhcp
diffutils sys-apps/diffutils
digikam media-gfx/digikam
dillo www-client/dillo
dosbox games-emulation/dosbox
dovecot net-mail/dovecot
doxygen app-doc/doxygen
e2fsprogs sys-fs/e2fsprogs
eclipse dev-util/eclipse-sdk
emacs app-editors/emacs
enlightenment x11-wm/enlightenment
epiphany www-client/epiphany
evolution mail-client/evolution
exim mail-mta/exim
fetchmail net-mail/fetchmail
ffmpeg media-video/ffmpeg
file sys-apps/file
findutils sys-apps/findutils
firebird dev-db/firebird
firefox www-client/mozilla-firefox
flex sys-devel/flex
fluxbox x11-wm/fluxbox
freetype media-libs/freetype
f-spot media-gfx/f-spot
gawk sys-apps/gawk
gcc sys-devel/gcc
gettext sys-devel/gettext
gftp net-ftp/gftp
ghostscript app-text/ghostscript-gpl
gimp media-gfx/gimp
git dev-util/git
glade dev-util/glade
glibc sys-libs/glibc
gnucash app-office/gnucash
gnumeric app-office/gnumeric
gnupg app-crypt/gnupg
gparted sys-block/gparted
grep sys-apps/grep
groff sys-apps/groff
grub sys-boot/grub
gstreamer media-libs/gstreamer
gtk+ x11-libs/gtk+
gzip app-arch/gzip
hal sys-apps/hal
httpd www-servers/apache
icewm x11-wm/icewm
ImageMagick media-gfx/imagemagick
inkscape media-gfx/inkscape
iptables net-firewall/iptables
jre dev-java/sun-jre-bin
k3b app-cdr/k3b
kaffeine media-video/kaffeine
kdebase kde-base/kde-meta
kdevelop dev-util/kdevelop
kdewebdev kde-base/kdewebdev
koffice app-office/koffice
krusader kde-misc/krusader
ktorrent net-p2p/ktorrent
less sys-apps/less
lftp net-ftp/lftp
libgnome gnome-base/libgnome
libselinux sys-libs/libselinux
libtool sys-devel/libtool
libvorbis media-libs/libvorbis
lighttpd www-servers/lighttpd
lilo sys-boot/lilo
links www-client/links
linux sys-kernel/vanilla-sources
lvm sys-fs/lvm2
lxde-common lxde-base/lxde-common
lynx www-client/lynx
lyx app-office/lyx
m4 sys-devel/m4
MailScanner mail-filter/MailScanner
make sys-devel/make
man sys-apps/man
man-pages sys-apps/man-pages
mc app-misc/mc
mod_perl www-apache/mod_perl
module-init-tools sys-apps/module-init-tools
mono dev-lang/mono
MPlayer media-video/mplayer
mutt mail-client/mutt
mysql dev-db/mysql
nautilus gnome-base/nautilus
ncftp net-ftp/ncftp
ncurses sys-libs/ncurses
ndiswrapper net-wireless/ndiswrapper
nedit app-editors/nedit
netatalk net-fs/netatalk
NetBeans dev-util/netbeans
NetworkManager net-misc/networkmanager
nmap net-analyzer/nmap
ntfs-3g sys-fs/ntfs3g
NVIDIA x11-drivers/nvidia-drivers
openbox x11-wm/openbox
openldap net-nds/openldap
OpenOffice.org app-office/openoffice
openssh net-misc/openssh
openssl dev-libs/openssl
openvas-client net-analyzer/openvas-client
opera www-client/opera
parted sys-apps/parted
perl dev-lang/perl
php dev-lang/php
phpMyAdmin dev-db/phpmyadmin
pidgin net-im/pidgin
postfix mail-mta/postfix
postgresql dev-db/postgresql-server
ppp net-dialup/ppp
procmail mail-filter/procmail
proftpd net-ftp/proftpd
pulseaudio media-sound/pulseaudio
Python dev-lang/python
qcad sci-misc/qcad
qemu app-emulation/qemu
qpopper net-mail/qpopper
qt-x11 x11-libs/qt
reiserfsprogs sys-fs/reiserfsprogs
rpm app-arch/rpm
rp-pppoe net-dialup/rp-pppoe
rsync net-misc/rsync
ruby dev-lang/ruby
samba net-fs/samba
sane-backends media-gfx/sane-backends
scim app-i18n/scim
screen app-misc/screen
scribus app-office/scribus
seamonkey www-client/seamonkey
sed sys-apps/sed
sendmail mail-mta/sendmail
snort net-analyzer/snort
SpamAssassin mail-filter/spamassassin
sqlite dev-db/sqlite
squid net-proxy/squid
squirrelmail mail-client/squirrelmail
subversion dev-util/subversion
sylpheed mail-client/sylpheed
sysvinit sys-apps/sysvinit
tar app-arch/tar
tcl dev-lang/tcl
tcpdump net-analyzer/tcpdump
texinfo sys-apps/texinfo
texlive app-text/texlive
thunderbird mail-client/mozilla-thunderbird
tightvnc net-misc/tightvnc
udev sys-fs/udev
util-linux sys-apps/util-linux
vim app-editors/vim
VirtualBox app-emulation/virtualbox-ose
vlc media-video/vlc
vnc net-misc/vnc
vsftpd net-ftp/vsftpd
webmin app-admin/webmin
wget net-misc/wget
wicd net-misc/wicd
WindowMaker x11-wm/windowmaker
wine app-emulation/wine
wireshark net-analyzer/wireshark
xchat net-irc/xchat
xen app-emulation/xen
xfce xfce-base/xfce4-meta
xfsprogs sys-fs/xfsprogs
xine-lib media-libs/xine-lib
xinetd sys-apps/xinetd
xorg-server x11-base/xorg-server
yaboot sys-boot/yaboot
yum sys-apps/yum
zlib sys-libs/zlib
Zope net-zope/zope

[gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Sat, 12 Sep 2009 01:02:44 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:

> Among other information the Gentoo page at DistroWatch [1] displays a
> table on about 200 selected packages [2] and how up to date Gentoo is
> per package.  I assume that DistroWatch is still one of the first places
> people go to get a feeling for a Distro they heard about, besides
> Wikpedia and ${distro}.org.
> 
> The freshness of these 200 packages have influence on how people
> perceive Gentoo on DistroWatch.  While the tree as a whole is what we
> should keep as up to date as possible keeping these 200 packages (list
> further down) up to date can therefore be of particular importance.

Personally I don't see how gaming the system helps us in any way.




Also, screw DW.

-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Aaron Bauman]

Sebastian,
	I definitely admire your point and know that through your tracking and Google 
SoC project you have good visibility on this I do however have to disagree.  
As much as I enjoy the open source community and admire the products they put 
out I do believe Gentoo has the right approach to packaging.
	My standpoint is that Gentoo always ensures stability in the fact that we 
require packages to be tested prior to release in the main portage tree and 
secondly the Gentoo developers always ensure security as best as they can.
	These I believe are what keep the portage tree somewhat behind the latest and 
greatest and as always there are overlays and options that allow users to pull 
these packages down if they want.
	I believe the great thing about Gentoo is the choice of whether to be cutting 
edge or not.  If I have missed anything please let me know.

On Friday 11 September 2009 19:02:44 Sebastian Pipping wrote:
> Hello there!
> 
> 
> Among other information the Gentoo page at DistroWatch [1] displays a
> table on about 200 selected packages [2] and how up to date Gentoo is
> per package.  I assume that DistroWatch is still one of the first places
> people go to get a feeling for a Distro they heard about, besides
> Wikpedia and ${distro}.org.
> 
> The freshness of these 200 packages have influence on how people
> perceive Gentoo on DistroWatch.  While the tree as a whole is what we
> should keep as up to date as possible keeping these 200 packages (list
> further down) up to date can therefore be of particular importance.
> 
> From a quick look at the table these packages seem to need extra care in
> Gentoo:
> 
>   cups (1.4.0)     1.3.11  <-- latest in Gentoo unstable/testing
>   koffice (2.0.2)  1.6.3
>   mysql (5.1.38)   5.0.84
>   perl (5.10.1)    5.8.8
>   php (5.3.0)      5.2.10
>   samba (3.4.1)    3.3.7
> 
> 
> Packages not found in Gentoo that DistroWatch monitors across discros are:
> 
>   apt
>   synaptic
>     .. Debian stuff, that Gentoo does not have packaged
> 
>   apache
>   mod_ssl
>     .. Apache 1.x seems gone from Gentoo (I suppose security)
> 
>   openjdk
>     .. Not packaged in Gentoo, no idea why
> 
>   checkinstall
>   Miro
>     .. Not in official tree (yet?), available through an Overlay
> 
>   xmms
>     .. Removed for security reasons, available through an Overlay
> 
> Maybe we should move Miro to the main tree?
> 
> 
> Since today DistroWatch's sources on tree freshness are [3] and [4] as
> they provide more accurate data than previously used sources do.
> 
> What is the process to migrate the generating script over to Gentoo
> infrastructure?
> 
> See you,
> 
> 
> 
> Sebastian
> 
> 
> [1] http://distrowatch.com/table.php?distribution=gentoo
> [2] http://distrowatch.com/packages.php
> [3] http://www.hartwork.org/public/distrowatch_gentoo_x86_latest_stable.txt
> [4]
> http://www.hartwork.org/public/distrowatch_gentoo_x86_latest_unstable.txt
> 
> 
> List of all Gentoo packages currently monitored
> ===============================================
> abiword app-office/abiword
> AfterStep x11-wm/afterstep
> alpine mail-client/alpine
> alsa-lib media-libs/alsa-lib
> amarok media-sound/amarok
> apache-tomcat www-servers/tomcat
> ati-driver x11-drivers/ati-drivers
> audacity media-sound/audacity
> autoconf sys-devel/autoconf
> automake sys-devel/automake
> avidemux media-video/avidemux
> banshee media-sound/banshee
> bash app-shells/bash
> bind net-dns/bind
> binutils sys-devel/binutils
> bison sys-devel/bison
> blender media-gfx/blender
> bluefish app-editors/bluefish
> bzip2 app-arch/bzip2
> cdrkit app-cdr/cdrkit
> cinelerra media-video/cinelerra
> compiz x11-wm/compiz
> coreutils sys-apps/coreutils
> cups net-print/cups
> curl net-misc/curl
> cvs dev-util/cvs
> db sys-libs/db
> DeviceKit sys-apps/devicekit
> dhcp net-misc/dhcp
> diffutils sys-apps/diffutils
> digikam media-gfx/digikam
> dillo www-client/dillo
> dosbox games-emulation/dosbox
> dovecot net-mail/dovecot
> doxygen app-doc/doxygen
> e2fsprogs sys-fs/e2fsprogs
> eclipse dev-util/eclipse-sdk
> emacs app-editors/emacs
> enlightenment x11-wm/enlightenment
> epiphany www-client/epiphany
> evolution mail-client/evolution
> exim mail-mta/exim
> fetchmail net-mail/fetchmail
> ffmpeg media-video/ffmpeg
> file sys-apps/file
> findutils sys-apps/findutils
> firebird dev-db/firebird
> firefox www-client/mozilla-firefox
> flex sys-devel/flex
> fluxbox x11-wm/fluxbox
> freetype media-libs/freetype
> f-spot media-gfx/f-spot
> gawk sys-apps/gawk
> gcc sys-devel/gcc
> gettext sys-devel/gettext
> gftp net-ftp/gftp
> ghostscript app-text/ghostscript-gpl
> gimp media-gfx/gimp
> git dev-util/git
> glade dev-util/glade
> glibc sys-libs/glibc
> gnucash app-office/gnucash
> gnumeric app-office/gnumeric
> gnupg app-crypt/gnupg
> gparted sys-block/gparted
> grep sys-apps/grep
> groff sys-apps/groff
> grub sys-boot/grub
> gstreamer media-libs/gstreamer
> gtk+ x11-libs/gtk+
> gzip app-arch/gzip
> hal sys-apps/hal
> httpd www-servers/apache
> icewm x11-wm/icewm
> ImageMagick media-gfx/imagemagick
> inkscape media-gfx/inkscape
> iptables net-firewall/iptables
> jre dev-java/sun-jre-bin
> k3b app-cdr/k3b
> kaffeine media-video/kaffeine
> kdebase kde-base/kde-meta
> kdevelop dev-util/kdevelop
> kdewebdev kde-base/kdewebdev
> koffice app-office/koffice
> krusader kde-misc/krusader
> ktorrent net-p2p/ktorrent
> less sys-apps/less
> lftp net-ftp/lftp
> libgnome gnome-base/libgnome
> libselinux sys-libs/libselinux
> libtool sys-devel/libtool
> libvorbis media-libs/libvorbis
> lighttpd www-servers/lighttpd
> lilo sys-boot/lilo
> links www-client/links
> linux sys-kernel/vanilla-sources
> lvm sys-fs/lvm2
> lxde-common lxde-base/lxde-common
> lynx www-client/lynx
> lyx app-office/lyx
> m4 sys-devel/m4
> MailScanner mail-filter/MailScanner
> make sys-devel/make
> man sys-apps/man
> man-pages sys-apps/man-pages
> mc app-misc/mc
> mod_perl www-apache/mod_perl
> module-init-tools sys-apps/module-init-tools
> mono dev-lang/mono
> MPlayer media-video/mplayer
> mutt mail-client/mutt
> mysql dev-db/mysql
> nautilus gnome-base/nautilus
> ncftp net-ftp/ncftp
> ncurses sys-libs/ncurses
> ndiswrapper net-wireless/ndiswrapper
> nedit app-editors/nedit
> netatalk net-fs/netatalk
> NetBeans dev-util/netbeans
> NetworkManager net-misc/networkmanager
> nmap net-analyzer/nmap
> ntfs-3g sys-fs/ntfs3g
> NVIDIA x11-drivers/nvidia-drivers
> openbox x11-wm/openbox
> openldap net-nds/openldap
> OpenOffice.org app-office/openoffice
> openssh net-misc/openssh
> openssl dev-libs/openssl
> openvas-client net-analyzer/openvas-client
> opera www-client/opera
> parted sys-apps/parted
> perl dev-lang/perl
> php dev-lang/php
> phpMyAdmin dev-db/phpmyadmin
> pidgin net-im/pidgin
> postfix mail-mta/postfix
> postgresql dev-db/postgresql-server
> ppp net-dialup/ppp
> procmail mail-filter/procmail
> proftpd net-ftp/proftpd
> pulseaudio media-sound/pulseaudio
> Python dev-lang/python
> qcad sci-misc/qcad
> qemu app-emulation/qemu
> qpopper net-mail/qpopper
> qt-x11 x11-libs/qt
> reiserfsprogs sys-fs/reiserfsprogs
> rpm app-arch/rpm
> rp-pppoe net-dialup/rp-pppoe
> rsync net-misc/rsync
> ruby dev-lang/ruby
> samba net-fs/samba
> sane-backends media-gfx/sane-backends
> scim app-i18n/scim
> screen app-misc/screen
> scribus app-office/scribus
> seamonkey www-client/seamonkey
> sed sys-apps/sed
> sendmail mail-mta/sendmail
> snort net-analyzer/snort
> SpamAssassin mail-filter/spamassassin
> sqlite dev-db/sqlite
> squid net-proxy/squid
> squirrelmail mail-client/squirrelmail
> subversion dev-util/subversion
> sylpheed mail-client/sylpheed
> sysvinit sys-apps/sysvinit
> tar app-arch/tar
> tcl dev-lang/tcl
> tcpdump net-analyzer/tcpdump
> texinfo sys-apps/texinfo
> texlive app-text/texlive
> thunderbird mail-client/mozilla-thunderbird
> tightvnc net-misc/tightvnc
> udev sys-fs/udev
> util-linux sys-apps/util-linux
> vim app-editors/vim
> VirtualBox app-emulation/virtualbox-ose
> vlc media-video/vlc
> vnc net-misc/vnc
> vsftpd net-ftp/vsftpd
> webmin app-admin/webmin
> wget net-misc/wget
> wicd net-misc/wicd
> WindowMaker x11-wm/windowmaker
> wine app-emulation/wine
> wireshark net-analyzer/wireshark
> xchat net-irc/xchat
> xen app-emulation/xen
> xfce xfce-base/xfce4-meta
> xfsprogs sys-fs/xfsprogs
> xine-lib media-libs/xine-lib
> xinetd sys-apps/xinetd
> xorg-server x11-base/xorg-server
> yaboot sys-boot/yaboot
> yum sys-apps/yum
> zlib sys-libs/zlib
> Zope net-zope/zope
> 

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Pipping wrote:
> Hello there!
> 
> 
> Among other information the Gentoo page at DistroWatch [1] displays a
> table on about 200 selected packages [2] and how up to date Gentoo is
> per package.  I assume that DistroWatch is still one of the first places
> people go to get a feeling for a Distro they heard about, besides
> Wikpedia and ${distro}.org.
> 
> The freshness of these 200 packages have influence on how people
> perceive Gentoo on DistroWatch.  While the tree as a whole is what we
> should keep as up to date as possible keeping these 200 packages (list
> further down) up to date can therefore be of particular importance.
> 
> From a quick look at the table these packages seem to need extra care in
> Gentoo:
> 
>   cups (1.4.0)     1.3.11  <-- latest in Gentoo unstable/testing
>   koffice (2.0.2)  1.6.3

There has been koffice-meta-2.0.2 for a while.

>   mysql (5.1.38)   5.0.84
>   perl (5.10.1)    5.8.8
>   php (5.3.0)      5.2.10
>   samba (3.4.1)    3.3.7

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqrhLwACgkQp/VmCx0OL2xRjQCfUPpebxYVEaUC2aMAgFGOm8ov
Y/oAoLWiRr4kXCsS/JCFb6R5mleJKCqi
=DENW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Ryan Hill wrote:
> Personally I don't see how gaming the system helps us in any way.

I was afraid it could be read in such a way.  Handing out fake version
numbers would be much easier, wouldn't it?  I want every single package
int he tree to be stable, up to date and polished.  But as our resources
are limited let's focus on packages that are most important first.


> Also, screw DW.

I'd be interested to hear details about your attitude off-list.



Sebastian

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Aaron Bauman wrote:
> Sebastian,
> 	I definitely admire your point and know that through your tracking and Google 
> SoC project you have good visibility on this I do however have to disagree.  
> As much as I enjoy the open source community and admire the products they put 
> out I do believe Gentoo has the right approach to packaging.
> 	My standpoint is that Gentoo always ensures stability in the fact that we 
> require packages to be tested prior to release in the main portage tree and 
> secondly the Gentoo developers always ensure security as best as they can.
> 	These I believe are what keep the portage tree somewhat behind the latest and 
> greatest and as always there are overlays and options that allow users to pull 
> these packages down if they want.
> 	I believe the great thing about Gentoo is the choice of whether to be cutting 
> edge or not.  If I have missed anything please let me know.

I don't think we should trade away quality.  You said you disagree with
me but with that said I don't see at which point.



Sebastian

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Marijn Schouten (hkBst) wrote:
>>   koffice (2.0.2)  1.6.3
> 
> There has been koffice-meta-2.0.2 for a while.

Good catch, thank you!



Sebastian

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Jesús Guerrero]

On Sat, 12 Sep 2009 01:02:44 +0200, Sebastian Pipping
<webmaster@hartwork.org> wrote:
> Hello there!
> 
> 
> Among other information the Gentoo page at DistroWatch [1] displays a
> table on about 200 selected packages [2] and how up to date Gentoo is
> per package.  I assume that DistroWatch is still one of the first places
> people go to get a feeling for a Distro they heard about, besides
> Wikpedia and ${distro}.org.

Seriously, I doubt that the average Gentoo user comes from Distrowatch.
Gentoo is born from a necessity which is very different from the usual
binary distro. Gentoo has never been about fame or marketing.

> The freshness of these 200 packages have influence on how people
> perceive Gentoo on DistroWatch.  While the tree as a whole is what we
> should keep as up to date as possible keeping these 200 packages (list
> further down) up to date can therefore be of particular importance.
> 
> From a quick look at the table these packages seem to need extra care in
> Gentoo:
> 
>   cups (1.4.0)     1.3.11  <-- latest in Gentoo unstable/testing
>   koffice (2.0.2)  1.6.3
>   mysql (5.1.38)   5.0.84
>   perl (5.10.1)    5.8.8
>   php (5.3.0)      5.2.10
>   samba (3.4.1)    3.3.7
> 
> 
> Packages not found in Gentoo that DistroWatch monitors across discros
are:
> 
>   apt
>   synaptic
>     .. Debian stuff, that Gentoo does not have packaged
> 
>   apache
>   mod_ssl
>     .. Apache 1.x seems gone from Gentoo (I suppose security)
> 
>   openjdk
>     .. Not packaged in Gentoo, no idea why
> 
>   checkinstall
>   Miro
>     .. Not in official tree (yet?), available through an Overlay
> 
>   xmms
>     .. Removed for security reasons, available through an Overlay
> 
> Maybe we should move Miro to the main tree?

Most Gentoo users will have no problem to use overlays as they need
them. If we had more developers we could as maintain more packages,
as simple as that.

Besides that, if you want some new version, you are free to use 
bugs.gentoo.org to submit a bug, version bump, or whatever.

-- 
Jesús Guerrero

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Richard Freeman]

Jesús Guerrero wrote:
> 
> Most Gentoo users will have no problem to use overlays as they need
> them. If we had more developers we could as maintain more packages,
> as simple as that.
> 

I actually tend to agree with this position, however to use overlays as 
a valid solution for end-users we need to do more to support them. 
Right now it is at least a little painful to get set up with an overlay. 
  There also isn't really any official place to vet overlays, and there 
isn't any official source for overlays that aren't maintained by gentoo.

Sure, overlays.g.o has tons of overlays - but which ones are 
mostly-stable, and which ones are intended to break systems?  What is 
the QA policy for each overlay?  If I'm an end-user not interested in 
breaking my system, what overlays are safe for me to use?

If we really want overlays to be an outlet to allow more non-devs to 
contribute, then there needs to be some way to standardize them.  Maybe 
a simple ratings system - an overlay needs to comply with one set of 
rules just to get listed on o.g.o.  If you want to be marked as stable, 
then you obey some additional rules.  And so on...

Then we can have overlays of various types for various purposes, and 
users can pick which ones they want to follow.  We could also have 
things like overlay groups - like "stable" or "desktop" or "KDE" / etc.

Maybe a fancy GUI to allow users to configure all of this.

Of course, for this to work somebody needs to develop it.  If somebody 
were willing to do the work I doubt anybody would get in their way.  It 
isn't like any of this would interfere with anybody who just wanted to 
make their own overlay without rules and not have it listed on some 
official site.

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Jesús Guerrero]

On Sun, 13 Sep 2009 06:47:27 -0400, Richard Freeman <rich0@gentoo.org>
wrote:
> Jesús Guerrero wrote:
>> 
>> Most Gentoo users will have no problem to use overlays as they need
>> them. If we had more developers we could as maintain more packages,
>> as simple as that.
>> 
> 
> I actually tend to agree with this position,

It's not something to agree or disagree. There aren't developers to
maintain
all the software under the sun, period.

> however to use overlays as 
> a valid solution for end-users we need to do more to support them. 

Yeah, devs for that as well.

> Right now it is at least a little painful to get set up with an overlay.


No, it's a matter of using layman -a <whatever>

>   There also isn't really any official place to vet overlays, and there 
> isn't any official source for overlays that aren't maintained by gentoo.
> 
> Sure, overlays.g.o has tons of overlays - but which ones are 
> mostly-stable, and which ones are intended to break systems?  What is 
> the QA policy for each overlay?  If I'm an end-user not interested in 
> breaking my system, what overlays are safe for me to use?

There's no policy. Just like unofficial repos for any other distro.
We can't control that. It's outside Gentoo.

While I agree that having more packages and being more up to date is
a good thing, I can never agree that we should sacrifice Gentoo for that.
You want stability for what I see on your answer, well, that's what you
have. I don't think we can do any more with the number of developers we
have right now unless we start dumping blindingly and without any check
every ebuild that we get across.

-- 
Jesús Guerrero

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

Richard Freeman schrieb:
> Jesús Guerrero wrote:
>>
>> Most Gentoo users will have no problem to use overlays as they need
>> them. If we had more developers we could as maintain more packages,
>> as simple as that.
>>
> 
> I actually tend to agree with this position, however to use overlays as
> a valid solution for end-users we need to do more to support them. Right
> now it is at least a little painful to get set up with an overlay.

I dont see any problem with "emerge layman; layman -L; layman -a <your preferred overlay>"

> Sure, overlays.g.o has tons of overlays - but which ones are
> mostly-stable, and which ones are intended to break systems?  What is
> the QA policy for each overlay?  If I'm an end-user not interested in
> breaking my system, what overlays are safe for me to use?

If developers create safe-to-use overlays, then i think, there is something wrong. Those ebuilds
shouldnt be hidden in any overlay, but instead be added and maintained in the main tree.

> If we really want overlays to be an outlet to allow more non-devs to
> contribute, then there needs to be some way to standardize them.  Maybe
> a simple ratings system - an overlay needs to comply with one set of
> rules just to get listed on o.g.o.  If you want to be marked as stable,
> then you obey some additional rules.  And so on...

If you want to use overlays to allow users to contribute and want to check the rules, you need devs,
who at least do basic QA checks on the overlay and all ebuilds. If this is done anyway, those devs
could also be proxy-maintainers. So those ebuilds, which comply to a set of rules could also go into
the main tree.

> 
> Then we can have overlays of various types for various purposes, and
> users can pick which ones they want to follow.  We could also have
> things like overlay groups - like "stable" or "desktop" or "KDE" / etc.
> 
> Maybe a fancy GUI to allow users to configure all of this.
> 
> Of course, for this to work somebody needs to develop it.  If somebody
> were willing to do the work I doubt anybody would get in their way.  It
> isn't like any of this would interfere with anybody who just wanted to
> make their own overlay without rules and not have it listed on some
> official site.

I think, this is the wrong direction. Instead of moving more and more things into overlays, we
should keep as much as possible in our main tree. With those two sets above removed, overlays would
either contain breaking stuff (playground for devs) or not checked ebuilds from users. For both
sets, the above ussage with layman should be easy enough.


-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Richard Freeman]

Jesús Guerrero wrote:
> Yeah, devs for that as well.
> 

Yup - I think we're actually on the same page.  Ultimately quality 
matters more than quantity and everybody does what they can given the 
resources we have.

>> Right now it is at least a little painful to get set up with an overlay.
> No, it's a matter of using layman -a <whatever>

Sure, and that is fine if overlays are intended only as experimental 
development spaces.  However, some (not necessarily including yourself) 
advocate that it is perfectly fine that the portage tree gets stale 
since we have all those overlays.  That certainly is a possible approach 
to take, but to go that route overlays need to become more robust. 
Right now they're really not a replacement for /usr/portage.

> There's no policy. Just like unofficial repos for any other distro.
> We can't control that. It's outside Gentoo.

Exactly.  And, because it is outside of Gentoo - packages in overlays 
don't count when we consider how up-to-date Gentoo is.  If we want to 
say that package foo isn't stale because there are recent versions in 
some overlay, then Gentoo needs to take responsibility for the overlays. 
  That might be as simple as being a gatekeeper - auditing overlays and 
booting ones that drift out of control.

> I don't think we can do any more with the number of developers we
> have right now unless we start dumping blindingly and without any check
> every ebuild that we get across.
> 

Absolutely.  The whole logic behind going to an overlay-based approach 
is that it allows developers to leverage external help more effectively 
- a developer can essentially delegate a whole mini portage-tree to some 
other entity to manage, simply providing oversight and QA.  In theory 
you could even have official overlays - which would allow better 
delineation of responsibilities (you don't need to grant people commit 
access to everything - just their project's overlay).

Ultimately, as you argue, it doesn't make a difference if nobody is 
willing to step up and actually maintain ebuilds.

Personally, I like the overlay idea, but right now it just isn't 
necessary.  In theory proxy maintainers work almost as well, and we're 
not really making heavy use of this model right now.  If we had hundreds 
of users submitting high-quality ebuilds in bugzilla and simply couldn't 
find enough devs to commit them all, then a more overlay-based approach 
would help reduce the bottleneck of having a centralized group of 
committers.  Right now we probably have far more devs than proxy-devs, 
so the need to delegate the tree further really isn't there.

[gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Duncan]

Jesús Guerrero posted on Sun, 13 Sep 2009 11:11:42 +0200 as excerpted:

> On Sat, 12 Sep 2009 01:02:44 +0200, Sebastian Pipping
> <webmaster@hartwork.org> wrote:
>> 
>> Among other information the Gentoo page at DistroWatch [1] displays a
>> table on about 200 selected packages [2] and how up to date Gentoo is
>> per package.  I assume that DistroWatch is still one of the first
>> places people go to get a feeling for a Distro they heard about,
>> besides Wikpedia and ${distro}.org.
> 
> Seriously, I doubt that the average Gentoo user comes from Distrowatch.
> Gentoo is born from a necessity which is very different from the usual
> binary distro. Gentoo has never been about fame or marketing.

++

[package listing of not in Gentoo tree or way outdated]
>>   Miro
>>     .. Not in official tree (yet?), available through an Overlay
>> 
>>   xmms
>>     .. Removed for security reasons, available through an Overlay
>> 
>> Maybe we should move Miro to the main tree?
> 
> Most Gentoo users will have no problem to use overlays as they need
> them.

Agreed.  Yes, overlays are perhaps a bit more trouble to setup than 
simply maintaining normal tree updates once setup.  But let's get some 
context here.  layman's no difficulty at all, really, when compared to 
the ordinary stuff we expect Gentoo users to do all the time.  Gentoo has 
never been about spoon-feeding and this is no exception.  Layman is a 
great and powerful tool, certainly, and like any powerful tool, it takes 
a bit of learning to use, before even the user should trust himself with 
it. =:^)  But that's more true of Gentoo itself than it is of layman, and 
anyone who can manage Gentoo can certainly manage layman with little 
trouble.

> If we had more developers we could as maintain more packages, as
> simple as that.

Indeed.

> Besides that, if you want some new version, you are free to use
> bugs.gentoo.org to submit a bug, version bump, or whatever.

I'm not so sure about this.  Sure, one can submit a bug, but would that 
have done any good on, say, kde4, one popular overlay people use, 
particularly during the period that portage didn't work with it?  What 
about the kde sets?  Would they be allowed in the tree just based on a 
bug?  The obvious answer is no, and there's good reasons for it.

I can see the argument both ways for putting stuff like that in the main 
tree -- masked, of course, and possibly in an obscure location that the 
PMs could ignore unless configured otherwise.  Personally, I'd like to 
see more of it in the main tree, hard-masked when necessary, instead of 
in the overlays.  But I have a strong suspicion I'd feel otherwise if I 
were one of the devs tasked with getting packages like that, particularly 
huge interrelated conglomerations of packages like that, actually into 
some sort of usable working (for ordinary Gentoo users. altho as I said 
above, they're already a cut above ordinary users) shape.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Dale]

Duncan wrote:
> Jesús Guerrero posted on Sun, 13 Sep 2009 11:11:42 +0200 as excerpted:
>
>   
>> On Sat, 12 Sep 2009 01:02:44 +0200, Sebastian Pipping
>> <webmaster@hartwork.org> wrote:
>>     
>>> Among other information the Gentoo page at DistroWatch [1] displays a
>>> table on about 200 selected packages [2] and how up to date Gentoo is
>>> per package.  I assume that DistroWatch is still one of the first
>>> places people go to get a feeling for a Distro they heard about,
>>> besides Wikpedia and ${distro}.org.
>>>       
>> Seriously, I doubt that the average Gentoo user comes from Distrowatch.
>> Gentoo is born from a necessity which is very different from the usual
>> binary distro. Gentoo has never been about fame or marketing.
>>     
>
> ++
>
>   
- -  I came here because of distrowatch.  I started with Mandrake 9.1
but didn't like the upgrade process.  I went to distrowatch to see what
else I could find to use.  I found about about Gentoo and here I am,
years later using Gentoo. 

Dale

:-)  :-) 

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Albert Hopkins]

On Sun, 2009-09-13 at 09:36 -0500, Dale wrote:
> >> Seriously, I doubt that the average Gentoo user comes from
> Distrowatch.
> >> Gentoo is born from a necessity which is very different from the
> usual
> >> binary distro. Gentoo has never been about fame or marketing.

> - -  I came here because of distrowatch.  I started with Mandrake 9.1
> but didn't like the upgrade process.  I went to distrowatch to see
> what
> else I could find to use.  I found about about Gentoo and here I am,
> years later using Gentoo. 

What do our market research people tell us? ;-)

-a

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Dale]

Albert Hopkins wrote:
> On Sun, 2009-09-13 at 09:36 -0500, Dale wrote:
>   
>>>> Seriously, I doubt that the average Gentoo user comes from
>>>>         
>> Distrowatch.
>>     
>>>> Gentoo is born from a necessity which is very different from the
>>>>         
>> usual
>>     
>>>> binary distro. Gentoo has never been about fame or marketing.
>>>>         
>
>   
>> - -  I came here because of distrowatch.  I started with Mandrake 9.1
>> but didn't like the upgrade process.  I went to distrowatch to see
>> what
>> else I could find to use.  I found about about Gentoo and here I am,
>> years later using Gentoo. 
>>     
>
> What do our market research people tell us? ;-)
>
> -a
>
>   

Good question.  How would a person know if distrowatch leads people to
Gentoo or not?  It's not like there is really any way to find out.

Dale

:-)  :-) 

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Patrick Lauer]

On Sunday 13 September 2009 13:30:13 Thomas Sachau wrote:
> Richard Freeman schrieb:
> > Jesús Guerrero wrote:
> >> Most Gentoo users will have no problem to use overlays as they need
> >> them. If we had more developers we could as maintain more packages,
> >> as simple as that.
> >
> > I actually tend to agree with this position, however to use overlays as
> > a valid solution for end-users we need to do more to support them. Right
> > now it is at least a little painful to get set up with an overlay.
> 
> I dont see any problem with "emerge layman; layman -L; layman -a <your
>  preferred overlay>"

First issue: How do I find out in which overlay stuff is?
Second issue: "I want foopackage and barpackage, but not your hacked gcc"
Overlays can overshadow tree packages, which can have undesired effects.

> If developers create safe-to-use overlays, then i think, there is something
>  wrong. Those ebuilds shouldnt be hidden in any overlay, but instead be
>  added and maintained in the main tree.

Exactly. I've annoyed a few people by moving stuff from their overlay to the 
tree because it had been stuck in the overlay for ages and users were 
wondering why we had no new versions. /usr/portage is my overlay :)

[snip] 
> I think, this is the wrong direction. Instead of moving more and more
>  things into overlays, we should keep as much as possible in our main tree.
Yes. That's one of the reasons I used gentoo in the past ... no fractured 
overlay mess like on other distros. One tree to rule them all. Now things are 
a bit more complicated ...

>  With those two sets above removed, overlays would either contain breaking
>  stuff (playground for devs) or not checked ebuilds from users. For both
>  sets, the above ussage with layman should be easy enough.
Indeed. And everything else should go into the tree.
Also, everyone contributing regularly to an overlay (like X-Drum, who has done 
an awesome job at maintaining Virtualbox) should sooner or later be recruited 
to work on the Big Overlay instead.

Which points at another problem - our recruiting isn't as active as it should 
be. Maybe we should have the Sith rule of gentoo dev'ing ... "Always two there 
are, a master and an apprentice". It should be every dev's goal to have at 
least one recruit at most times :)

Or for those of you too lazy for that - do whatever you can to recruit your 
replacement. Once you've managed that you can be as lazy as you want!

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Jesús Guerrero]

On Sun, 13 Sep 2009 20:57:48 +0200, Patrick Lauer <patrick@gentoo.org>
wrote:
> 
> First issue: How do I find out in which overlay stuff is?

http://gentoo.zapto.org/

> Second issue: "I want foopackage and barpackage, but not your hacked
gcc"
> Overlays can overshadow tree packages, which can have undesired effects.

Smart overlays shouldn't do that (and if you are using ~arch then it's
*your* problem). No one forces you to get the full overlay though. You can
put the overlay out of the PORTDIR_OVERLAY, and then just symlink the
wanted
directories into your PORTDIR_OVERLAY, that way you will get the
facilities
of layman and the advantage or a greater control.


>>  With those two sets above removed, overlays would either contain
>>  breaking
>>  stuff (playground for devs) or not checked ebuilds from users. For
both
>>  sets, the above ussage with layman should be easy enough.
> Indeed. And everything else should go into the tree.
> Also, everyone contributing regularly to an overlay (like X-Drum, who
has
> done 
> an awesome job at maintaining Virtualbox) should sooner or later be
> recruited 
> to work on the Big Overlay instead.
> 
> Which points at another problem - our recruiting isn't as active as it
> should 
> be. Maybe we should have the Sith rule of gentoo dev'ing ... "Always two
> there 
> are, a master and an apprentice". It should be every dev's goal to have
at 
> least one recruit at most times :)
> 
> Or for those of you too lazy for that - do whatever you can to recruit
> your 
> replacement. Once you've managed that you can be as lazy as you want!

Yep. All comes down to the same, lack of man power I think.
-- 
Jesús Guerrero

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Alexander Færøy]

On Sun, Sep 13, 2009 at 08:57:48PM +0200, Patrick Lauer wrote:
> First issue: How do I find out in which overlay stuff is?

Paludis' solution to that issue is the unavailable repository[1].  It is
a repository that contains enough information about the packages in the
repositories to display information about them without being able to
install them. It works surprisingly well and it might be an idea worth
looking at.

> Second issue: "I want foopackage and barpackage, but not your hacked gcc"
> Overlays can overshadow tree packages, which can have undesired effects.

Support for overlay information in package.mask?


[1] http://paludis.pioto.org/configuration/repositories/unavailable.html

-- 
Alexander Færøy

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Jesús Guerrero wrote:
> On Sun, 13 Sep 2009 06:47:27 -0400, Richard Freeman <rich0@gentoo.org>
>> Right now it is at least a little painful to get set up with an overlay.
> 
> No, it's a matter of using layman -a <whatever>

I think Richard was including the manual setup required to use layman
and the procedure required to add overlays that are not in
layman-global.txt.  I agree, that both are no fun.  I wrote a tool
"layman-add" a while back to ease up the latter, because I felt it sucks
so badly.



Sebastian

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Richard Freeman wrote:
> Personally, I like the overlay idea, but right now it just isn't
> necessary.  In theory proxy maintainers work almost as well, and we're
> not really making heavy use of this model right now.

I disagree about this.  One of the reasons my overlay is fun to me is
because I am _not_ proxied.



Sebastian

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Patrick Lauer]

On Sunday 13 September 2009 21:03:13 Jesús Guerrero wrote:
> On Sun, 13 Sep 2009 20:57:48 +0200, Patrick Lauer <patrick@gentoo.org>
> 
> wrote:
> > First issue: How do I find out in which overlay stuff is?
> 
> http://gentoo.zapto.org/

That's not an official project, not mentioned in the layman docs afaik (feel 
free to prove me wrong :) ) and only list the overlays in the layman config.
It's just one step above "fetch from the bugzilla bug" ;)
(Ok, I'm exaggerating a bit, but it's still very user-unfriendly ...)
 
> > Second issue: "I want foopackage and barpackage, but not your hacked gcc"
> > Overlays can overshadow tree packages, which can have undesired effects.
> 
> Smart overlays shouldn't do that (and if you are using ~arch then it's
> *your* problem). 
How would you avoid it? If I had an overlay I'd dump everything in it that 
looks remotely interesting to me, and I don't care what you think should be in 
my overlay ;)

> No one forces you to get the full overlay though. You can
> put the overlay out of the PORTDIR_OVERLAY, and then just symlink the
> wanted directories into your PORTDIR_OVERLAY, that way you will get the
> facilities of layman and the advantage or a greater control.
*stab*

That's instant headache (dependencies!) and just a dirty hack around having 
the packages in the tree. I'm surprised that you are willing to spend so much 
energy on hacking around stuff, but unwilling to fix stuff directly. I'm far 
too lazy for such things :)

> Yep. All comes down to the same, lack of man power I think.
Always. And if you ever think you're done some users file some new bugs :)
So if you feel unhappy about things go fix them. You have the power!
(And any excuse that you are not talented enough or whatever ... look, they 
let me commit to the tree too!)

Plus there's all the other fronts in the battle for the best linux distro. 
Bugwrangling, documentation maintenance, security issues, ... there are enough 
possibilities even for those that can't or don't want to work on ebuilds 
directly. Just start working on stuff, ask when you need help and it'll be 
even better soon.

See? It's easy. And you have no excuse not to help. Now just do stuff! :) 

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Sebastian Pipping]

Alexander Færøy wrote:
>> Second issue: "I want foopackage and barpackage, but not your hacked gcc"
>> Overlays can overshadow tree packages, which can have undesired effects.
> 
> Support for overlay information in package.mask?

Once we have repository-specific atoms we get that for free.
Maybe we can not make it take ages somehow.



Sebastian

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Dale wrote:
> Good question.  How would a person know if distrowatch leads people to
> Gentoo or not?  It's not like there is really any way to find out.

- analysing referrer logs
- doing polls



sebastian

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Sebastian Pipping]

Duncan wrote:
> Agreed.  Yes, overlays are perhaps a bit more trouble to setup than 
> simply maintaining normal tree updates once setup.  But let's get some 
> context here.  layman's no difficulty at all, really, when compared to 
> the ordinary stuff we expect Gentoo users to do all the time.  Gentoo has 
> never been about spoon-feeding and this is no exception.  Layman is a 
> great and powerful tool, certainly, and like any powerful tool, it takes 
> a bit of learning to use, before even the user should trust himself with 
> it. =:^)  But that's more true of Gentoo itself than it is of layman, and 
> anyone who can manage Gentoo can certainly manage layman with little 
> trouble.

I think you forget about the learning curve: Gentoo users are not born
as Gentoo users.  They are coming from other distros (say Debian or Ubuntu).

For me it was unmasking that confused me a lot in the beginning.
There is three different kinds, one is not in "the books" afaik and it's
no fun to me to do.  I guess without autounmask by now I would be so
frustrated to not use Gentoo anymore.

Seriously, stuff like the layman setup mess is another tiny reason
keeping our user base smaller than needed, keeping our recruiting rates
down.



Sebastian

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Alexander Færøy]

On Sun, Sep 13, 2009 at 09:45:59PM +0200, Sebastian Pipping wrote:
> Once we have repository-specific atoms we get that for free.
> Maybe we can not make it take ages somehow.

Indeed. Perhaps it is time for the users to start bribing Zac.

-- 
Alexander Færøy

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Sun, 13 Sep 2009 21:45:59 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:
> Alexander Færøy wrote:
> >> Second issue: "I want foopackage and barpackage, but not your
> >> hacked gcc" Overlays can overshadow tree packages, which can have
> >> undesired effects.
> > 
> > Support for overlay information in package.mask?
> 
> Once we have repository-specific atoms we get that for free.

Not quite. If both an overlay and the main tree provide foo-1.2,
masking foo-1.2::overlay in Portage would end up masking every foo-1.2.
You also need proper multiple repository support to make it work;
merely adding repo dep specs on top of a pure overlay model isn't
enough.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Jesús Guerrero]

On Sun, 13 Sep 2009 21:41:13 +0200, Patrick Lauer <patrick@gentoo.org>
wrote:
> On Sunday 13 September 2009 21:03:13 Jesús Guerrero wrote:
>> On Sun, 13 Sep 2009 20:57:48 +0200, Patrick Lauer <patrick@gentoo.org>
>> 
>> wrote:
>> > First issue: How do I find out in which overlay stuff is?
>> 
>> http://gentoo.zapto.org/
> 
> That's not an official project, not mentioned in the layman docs afaik
> (feel 
> free to prove me wrong :) ) and only list the overlays in the layman
> config.
> It's just one step above "fetch from the bugzilla bug" ;)
> (Ok, I'm exaggerating a bit, but it's still very user-unfriendly ...)

I don't know what your point there is. Layman is not official either as
far as I know, and the overlays are unsupported by Gentoo directly.

>> > Second issue: "I want foopackage and barpackage, but not your hacked
>> > gcc"
>> > Overlays can overshadow tree packages, which can have undesired
>> > effects.
>> 
>> Smart overlays shouldn't do that (and if you are using ~arch then it's
>> *your* problem). 
> How would you avoid it? If I had an overlay I'd dump everything in it
that 
> looks remotely interesting to me, and I don't care what you think should
> be in 
> my overlay ;)

How? ~arch keywords? And, if you are in ~arch, then you are smart enough
to live with this as well.

>> Yep. All comes down to the same, lack of man power I think.
> Always. And if you ever think you're done some users file some new bugs
:)
> So if you feel unhappy about things go fix them. You have the power!
> (And any excuse that you are not talented enough or whatever ... look,
> they 
> let me commit to the tree too!)
> 
> Plus there's all the other fronts in the battle for the best linux
distro. 
> Bugwrangling, documentation maintenance, security issues, ... there are
> enough 
> possibilities even for those that can't or don't want to work on ebuilds

> directly. Just start working on stuff, ask when you need help and it'll
be 
> even better soon.
> 
> See? It's easy. And you have no excuse not to help. Now just do stuff!
:)

No. It's not me who's unhappy about the current status of things ;)

I already do my work in other areas and I have no more time than I
devote to Gentoo already. I maintain overlays to a minimum, and when
I need an overlay I just pick it and put it into my personal overlay.

Yes, every forum staffer could very well become a developer and spend
their time doing some ebuilding, but then we would have a crappy forum
full of spam (believe me, it takes time to keep it clean) :)
-- 
Jesús Guerrero

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Sebastian Pipping]

Ciaran McCreesh wrote:
> Not quite. If both an overlay and the main tree provide foo-1.2,
> masking foo-1.2::overlay in Portage would end up masking every foo-1.2.

Why?


> You also need proper multiple repository support to make it work;
> merely adding repo dep specs on top of a pure overlay model isn't
> enough.

Please elaborate on that.



Sebastian

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Dale]

Sebastian Pipping wrote:
> Dale wrote:
>   
>> Good question.  How would a person know if distrowatch leads people to
>> Gentoo or not?  It's not like there is really any way to find out.
>>     
>
> - analysing referrer logs
> - doing polls
>
>
>
> sebastian
>
>
>   

Where are these referrer logs?  I don't recall ever doing one of those. 

Hasn't it been said before that Gentoo polls are pretty difficult to do
and not very accurate?  Only very few would respond to a poll.  Most
would not even know the was going on.


Dale

:-)  :-) 

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Sun, 13 Sep 2009 16:25:19 -0500, Dale <rdalek1967@gmail.com> wrote:

> 
> Where are these referrer logs?  I don't recall ever doing one of
> those. 
> 

They are in the web server logs. Apache includes them in the "combined"
log format, or you can add them in a custom log format.

So cooperation with Infra is required for this sort of analysis.

> Hasn't it been said before that Gentoo polls are pretty difficult to
> do and not very accurate?  

I fail to see the difficulty of both creating and filling out a survey
on a forums post. 
Also, accuracy is always an issue when doing online surveys as people
can submit it multiple times, and there's always the kids that just
click something out of boredom. Don't think that problem is specific to
Gentoo polls.

Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Dale]

Alex Legler wrote:
> On Sun, 13 Sep 2009 16:25:19 -0500, Dale <rdalek1967@gmail.com> wrote:
>
>   
>> Where are these referrer logs?  I don't recall ever doing one of
>> those. 
>>
>>     
>
> They are in the web server logs. Apache includes them in the "combined"
> log format, or you can add them in a custom log format.
>
> So cooperation with Infra is required for this sort of analysis.
>
>   
>> Hasn't it been said before that Gentoo polls are pretty difficult to
>> do and not very accurate?  
>>     
>
> I fail to see the difficulty of both creating and filling out a survey
> on a forums post. 
> Also, accuracy is always an issue when doing online surveys as people
> can submit it multiple times, and there's always the kids that just
> click something out of boredom. Don't think that problem is specific to
> Gentoo polls.
>
> Alex
>   

As has been said before, a lot of people don't go to the forums to see
the poll.  I only go to the forums to search if I have a problem before
posting to the list.  There may have been a dozen polls on the forums
and I would have no idea they happened. 

Of course, the same could be said about doing a poll on the mailing
lists as well.  Some Gentoo users that use the forums may not even know
the mailing lists exists. 

I'm not sure any poll could really be accurate no matter which means is
used.  Add in the kids you thought of and it just adds more confusion.

Dale

:-)  :-) 

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On Sun, 13 Sep 2009 17:08:38 -0500, Dale <rdalek1967@gmail.com> wrote:

> As has been said before, a lot of people don't go to the forums to see
> the poll.  I only go to the forums to search if I have a problem
> before posting to the list.  There may have been a dozen polls on the
> forums and I would have no idea they happened. 
> 

That might be /your personal/ behavior.

> Of course, the same could be said about doing a poll on the mailing
> lists as well.  Some Gentoo users that use the forums may not even
> know the mailing lists exists. 
> 

Do the poll in the Forums. Advertise it on planet, some MLs, maybe the
g.o front page, and on IRC.
That way we reach the users that don't go to the forums, but are on
IRC, and the folks that are on the forums but don't know of the MLs and
vice-versa.

Of course there'll be still people that don't know anything about the
thing, but *shrug*. Those who care, know. And those who don't care,
don't need to know, we have made our effort to reach people.

> I'm not sure any poll could really be accurate no matter which means
> is used.  

Maybe that is something we just need to live with. Guess all the other
people who do Internet polls do.

Besides, what can we lose? I don't think Sebastian would mind
preparing and posting the survey. A little more community participation
and a little less time spent talking instead of doing would do us good.

Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Dale]

Alex Legler wrote:
> On Sun, 13 Sep 2009 17:08:38 -0500, Dale <rdalek1967@gmail.com> wrote:
>
>   
>> As has been said before, a lot of people don't go to the forums to see
>> the poll.  I only go to the forums to search if I have a problem
>> before posting to the list.  There may have been a dozen polls on the
>> forums and I would have no idea they happened. 
>>
>>     
>
> That might be /your personal/ behavior.
>   

May be true but someone else mentioned that back when I was going to the
forums.  I hadn't thought of it until then. 


>   
>> Of course, the same could be said about doing a poll on the mailing
>> lists as well.  Some Gentoo users that use the forums may not even
>> know the mailing lists exists. 
>>
>>     
>
> Do the poll in the Forums. Advertise it on planet, some MLs, maybe the
> g.o front page, and on IRC.
> That way we reach the users that don't go to the forums, but are on
> IRC, and the folks that are on the forums but don't know of the MLs and
> vice-versa.
>
> Of course there'll be still people that don't know anything about the
> thing, but *shrug*. Those who care, know. And those who don't care,
> don't need to know, we have made our effort to reach people.
>
>   
>> I'm not sure any poll could really be accurate no matter which means
>> is used.  
>>     
>
> Maybe that is something we just need to live with. Guess all the other
> people who do Internet polls do.
>
> Besides, what can we lose? I don't think Sebastian would mind
> preparing and posting the survey. A little more community participation
> and a little less time spent talking instead of doing would do us good.
>
> Alex
>   

I agree that you can only put forth your best effort.  I just wouldn't
etch the results in stone.  Maybe a pencil would be OK tho.

Dale

:-)  :-) 

[gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Sat, 12 Sep 2009 14:15:34 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:

> Ryan Hill wrote:
> > Personally I don't see how gaming the system helps us in any way.
> 
> I was afraid it could be read in such a way.  Handing out fake version
> numbers would be much easier, wouldn't it?  I want every single package
> int he tree to be stable, up to date and polished.  But as our resources
> are limited let's focus on packages that are most important first.

That's actually what I meant by gaming the system.  We could keep those
particular packages up to the minute, but it wouldn't reflect the state of
our distro as a whole.  It's a false metric and I don't see the advantage in
pandering to it.  It's much more important that our packages actually work
together than have the highest numbers.

> > Also, screw DW.
> 
> I'd be interested to hear details about your attitude off-list.

Sorry, bad way of putting what Jesús later said; we're not in competition.
DistroWatch scores are the least of our worries.


-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Sun, 13 Sep 2009 22:17:19 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:
> Ciaran McCreesh wrote:
> > Not quite. If both an overlay and the main tree provide foo-1.2,
> > masking foo-1.2::overlay in Portage would end up masking every
> > foo-1.2.
> 
> Why?

Because an overlay model has only a single foo-1.2. Think of it like
stacks of paper. You've got your main repository:

  ::gentoo    foo-1.1 foo-1.2 foo-1.3

and on top of that you put your overlay:

  ::extras          foo-1.2         foo-1.4
  ::gentoo  foo-1.1 foo-1.2 foo-1.3

and then looking down from the top, all an overlay model package
manager sees is the foo-1.2 from the overlay. There's no
foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
that's made from (gentoo + extras).

There's a different way of looking at it that focuses more on the
repository level view at [1].

[1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Sebastian Pipping]

Ciaran McCreesh wrote:
> Because an overlay model has only a single foo-1.2. Think of it like
> stacks of paper. You've got your main repository:
> 
>   ::gentoo    foo-1.1 foo-1.2 foo-1.3
> 
> and on top of that you put your overlay:
> 
>   ::extras          foo-1.2         foo-1.4
>   ::gentoo  foo-1.1 foo-1.2 foo-1.3
> 
> and then looking down from the top, all an overlay model package
> manager sees is the foo-1.2 from the overlay. There's no
> foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
> that's made from (gentoo + extras).

I see.  So it would not work for dependencies but it should work for
masking.  That alone wouldn't make me happy, though.


> There's a different way of looking at it that focuses more on the
> repository level view at [1].
> 
> [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/

Interesting read.  Can you think of anything technical that would make
moving portage to this model impossible?



Sebastian

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Mon, 14 Sep 2009 20:28:26 +0200
Sebastian Pipping <webmaster@hartwork.org> wrote:
> Ciaran McCreesh wrote:
> > Because an overlay model has only a single foo-1.2. Think of it like
> > stacks of paper. You've got your main repository:
> > 
> >   ::gentoo    foo-1.1 foo-1.2 foo-1.3
> > 
> > and on top of that you put your overlay:
> > 
> >   ::extras          foo-1.2         foo-1.4
> >   ::gentoo  foo-1.1 foo-1.2 foo-1.3
> > 
> > and then looking down from the top, all an overlay model package
> > manager sees is the foo-1.2 from the overlay. There's no
> > foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
> > that's made from (gentoo + extras).
> 
> I see.  So it would not work for dependencies but it should work for
> masking.  That alone wouldn't make me happy, though.

I don't think it would necessarily work for masking either the way
Portage sees it (although iirc it would have done for the way Pkgcore
did things). Masking doesn't make foo-1.2::extras invisible, it just
makes it visible but unusable. Even if you do take the "ignore masked
things entirely" approach, the behaviour's highly weird when things
like repository package.masks become involved -- I'm not sure you could
define a consistent model that does 'the right thing' purely on
overlays (although feel free to try...).

> > There's a different way of looking at it that focuses more on the
> > repository level view at [1].
> > 
> > [1]:
> > http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/
> 
> Interesting read.  Can you think of anything technical that would make
> moving portage to this model impossible?

Other than the usual problems with moving Portage to things? No. The
multiple repository model works fine with Gentoo, and it's possible to
set it up so that it looks to the user exactly like an overlay model
except where ::repo deps are involved.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Zac Medico]

Sebastian Pipping wrote:
> Ciaran McCreesh wrote:
>> Because an overlay model has only a single foo-1.2. Think of it like
>> stacks of paper. You've got your main repository:
>>
>>   ::gentoo    foo-1.1 foo-1.2 foo-1.3
>>
>> and on top of that you put your overlay:
>>
>>   ::extras          foo-1.2         foo-1.4
>>   ::gentoo  foo-1.1 foo-1.2 foo-1.3
>>
>> and then looking down from the top, all an overlay model package
>> manager sees is the foo-1.2 from the overlay. There's no
>> foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2
>> that's made from (gentoo + extras).
> 
> I see.  So it would not work for dependencies but it should work for
> masking.  That alone wouldn't make me happy, though.
> 
> 
>> There's a different way of looking at it that focuses more on the
>> repository level view at [1].
>>
>> [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/
> 
> Interesting read.  Can you think of anything technical that would make
> moving portage to this model impossible?

It shouldn't be too difficult to tweak portage so that multiple
ebuilds of the same version from different repositories are visible
to portage's dependency resolver. Currently, it uses a collection of
3 repositories to resolve dependencies: installed, ebuild, and
binary packages. Replacing the single ebuild repository (portdbapi
class) instance with multiple instances, one for each overlay,
should produce the desired result.
-- 
Thanks,
Zac

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Sebastian Pipping]

Zac Medico wrote:
> It shouldn't be too difficult to tweak portage so that multiple
> ebuilds of the same version from different repositories are visible
> to portage's dependency resolver. Currently, it uses a collection of
> 3 repositories to resolve dependencies: installed, ebuild, and
> binary packages. Replacing the single ebuild repository (portdbapi
> class) instance with multiple instances, one for each overlay,
> should produce the desired result.

Sounds good.  How long do you expect it to take?



Sebastian

Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]

[Zac Medico]

Sebastian Pipping wrote:
> Zac Medico wrote:
>> It shouldn't be too difficult to tweak portage so that multiple
>> ebuilds of the same version from different repositories are visible
>> to portage's dependency resolver. Currently, it uses a collection of
>> 3 repositories to resolve dependencies: installed, ebuild, and
>> binary packages. Replacing the single ebuild repository (portdbapi
>> class) instance with multiple instances, one for each overlay,
>> should produce the desired result.
> 
> Sounds good.  How long do you expect it to take?

Not long. It seems like a reasonably useful feature, so I'll go
ahead and try to get it done sometime during the next few days. Then
I'll be able to include it in the portage-2.1.7 branch which I plan
to create soon. You can track progress on this bug:

  http://bugs.gentoo.org/show_bug.cgi?id=262038
-- 
Thanks,
Zac

[gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Duncan]

Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted:

> Duncan wrote:
>> [L]et's get some context here.  layman's no difficulty at all, really,
>> when compared to the ordinary stuff we expect Gentoo users to do all
>> the time.
> 
> I think you forget about the learning curve: Gentoo users are not born
> as Gentoo users.  They are coming from other distros (say Debian or
> Ubuntu).

Not forgetting that, but perhaps forgetting how "unordinary" my own 
experience was.  I came from Mandrake, but researched Gentoo well enough 
that I was already explaining portage basics based on the material in the 
Handbook, etc, on the user list (and reading the dev list), before I even 
had Gentoo installed.

I like to think that if I can do it, everybody can, but regardless of 
whether they /can/ or not, it's a fact that not everybody /does/, as 
demonstrated by the fact that people were asking the questions I was 
answering.

I /do/ sometimes forget /that/ end of it, that for whatever reason, not 
everybody chooses to read the handbook, etc, even if it's ultimately only 
making the job of sysadmining their own Gentoo boxen an order of 
magnitude harder than it should be.

> For me it was unmasking that confused me a lot in the beginning. There
> is three different kinds, one is not in "the books" afaik and it's no
> fun to me to do.  I guess without autounmask by now I would be so
> frustrated to not use Gentoo anymore.

You have me wondering now what's "not in the books."  I'd guess the three 
types of masking must be (entirely) unkeyworded, ~arch keyworded, and 
hard-masked (package.mask-ed), but again, unless that material has 
actually been /removed/ from the handbook since 2004, I was actually 
explaining all that to others even from my still Mandrake system, so 
it's /certainly/ in the books!

And I don't need for autounmask, tho I do run ~arch.  But the thing is, 
if people are running enough individual ~arch packages so handling it 
manually is difficult enough they need a tool for it, from my viewpoint, 
they should seriously consider running ~arch anyway, since stable is 
tested, and ~arch is somewhat tested, but nobody much tests a half-and-
half system nor could it be practically so in any case since there's just 
too many millions of variants there to test, so trying to run such a half-
and-half system is really asking for more trouble than trying to run a 
full ~arch system.

But with a few small refinements over the years as Gentoo and its FLOSS 
environment have changed, again, that's very close to the same position 
and explanation I took from the very beginning, while I was still working 
on my first install.

> Seriously, stuff like the layman setup mess is another tiny reason
> keeping our user base smaller than needed, keeping our recruiting rates
> down.

I guess I just don't see it.  There's a reason the packages on the 
overlays aren't yet part of the tree, because in general, either the 
ebuilds (if not the upstream packages) aren't yet mature enough to be in-
tree (at least unmasked, in-tree), or they're community ebuilds, not 
Gentoo-dev vetted ones.  Keeping that distinction, for the protection of 
both Gentoo and its users, is a deliberate policy.  Those who are mature 
enough to handle the risks of overlays can get them with little problem, 
while those newbies who self-evidently are NOT mature enough in their 
Gentoo usage to properly handle the risk (or it'd not be a problem for 
them in the first place since they'd be comfortable with the tools and 
how to use them), are by deliberate policy, kept away from the additional 
risk and danger.

Other than minor refinements here or there, I just don't see how that can 
or should be changed, unless we're simply deciding that policy is wrong-
headed, so damn the torpedoes headed for our users, full steam ahead, let 
them at them!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Angelo Arrifano]

Duncan wrote:
> Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted:
> 
>> Duncan wrote:
>>> [L]et's get some context here.  layman's no difficulty at all, really,
>>> when compared to the ordinary stuff we expect Gentoo users to do all
>>> the time.
>> I think you forget about the learning curve: Gentoo users are not born
>> as Gentoo users.  They are coming from other distros (say Debian or
>> Ubuntu).
> 
> Not forgetting that, but perhaps forgetting how "unordinary" my own 
> experience was.  I came from Mandrake, but researched Gentoo well enough 
> that I was already explaining portage basics based on the material in the 
> Handbook, etc, on the user list (and reading the dev list), before I even 
> had Gentoo installed.

My first distro was also Mandrake. I eventually moved endlessly between
Red Hat (before forking into Fedora) and Mandrake. The reason was the
broken rpm package manager (and repo) which had a peculiar way of naming
library .so names which interfered with my "hand-built" packages.

I found Gentoo when a friend of mine told me there was a distro which
was capable of producing CPU *optimized* code because all the packages
were built from source. At the time (6~7 years ago?), I didn't have idea
such distro could exist but that idea made sense and was left hard-coded
in my head.

That is when I read the *Gentoo philosophy* page (yes, there is people
that reads it) and immediately got in love with it. That was Gentoo's
biggest selling point for me. Then the handbook followed and you can
probably guess the rest of the story.

> 
> I like to think that if I can do it, everybody can, but regardless of 
> whether they /can/ or not, it's a fact that not everybody /does/, as 
> demonstrated by the fact that people were asking the questions I was 
> answering.

I think it is not a matter of capable of doing it or not but rather
matching one's needs. It is also a fact that most people *don't get it*
when it comes to the question *why gentoo*.
> 
> I /do/ sometimes forget /that/ end of it, that for whatever reason, not 
> everybody chooses to read the handbook, etc, even if it's ultimately only 
> making the job of sysadmining their own Gentoo boxen an order of 
> magnitude harder than it should be.
> 
>> For me it was unmasking that confused me a lot in the beginning. There
>> is three different kinds, one is not in "the books" afaik and it's no
>> fun to me to do.  I guess without autounmask by now I would be so
>> frustrated to not use Gentoo anymore.

The most confusing stuff for me was to learn all the GNU/Linux basics
that I had as granted while using other distros.

(...)

Just my 2 cents about what mattered to *me* (and still matters) when I
moved to Gentoo.
-- 
Angelo Arrifano AKA MiKNiX
Gentoo Embedded/OMAP850 Developer
Linwizard Developer
http://www.gentoo.org/~miknix
http://miknix.homelinux.com

Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future

[Donnie Berkholz]

On 20:46 Sun 13 Sep     , Ryan Hill wrote:
> On Sat, 12 Sep 2009 14:15:34 +0200
> Sebastian Pipping <webmaster@hartwork.org> wrote:
> > Ryan Hill wrote:
> > > Personally I don't see how gaming the system helps us in any way.
> > 
> > I was afraid it could be read in such a way.  Handing out fake version
> > numbers would be much easier, wouldn't it?  I want every single package
> > int he tree to be stable, up to date and polished.  But as our resources
> > are limited let's focus on packages that are most important first.
> 
> That's actually what I meant by gaming the system.  We could keep those
> particular packages up to the minute, but it wouldn't reflect the state of
> our distro as a whole.  It's a false metric and I don't see the advantage in
> pandering to it.  It's much more important that our packages actually work
> together than have the highest numbers.

At the same time, we also want to ensure that any badly out-of-date 
packages on there aren't outliers that reflect poorly on our actual 
average status. And frankly, having any way to monitor popular yet 
outdated packages is a good thing.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com