Mailing List Archive

DistroWatch and Gentoo packages: status quo and future
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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
Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
-----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: Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future] [ In reply to ]
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
Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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.
Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future] [ In reply to ]
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: overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future] [ In reply to ]
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: overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future] [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future] [ In reply to ]
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: overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future] [ In reply to ]
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: Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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: Re: DistroWatch and Gentoo packages: status quo and future [ In reply to ]
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

1 2  View All