* [RFC] duplicate recipes
@ 2010-02-28 20:01 Frans Meulenbroeks
2010-02-28 20:06 ` Koen Kooi
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Frans Meulenbroeks @ 2010-02-28 20:01 UTC (permalink / raw)
To: openembedded-devel
Below is a list of all recipes that have 5 or more versions.
Guess a lot of these are deadwood.
Proposal is to do some cleaning for these.
Probably the best scenario is to remove all versions which
- are not the latest version
- are not pinned with PREFERRED_VERSION in conf/distro/*
- do not have the largest DEFAULT_PREFERENCE
What do people feel about this?
Frans.
26 glib-2.0/glib-2.0
26 gcc/gcc-cross
25 gcc/gcc-cross-intermediate
25 gcc/gcc-cross-initial
25 gcc/gcc
24 linux/linux
22 binutils/binutils-cross
22 binutils/binutils
18 gcc/gcc-cross-sdk
16 glibc/glibc
15 xserver-common/xserver-common
14 linux-libc-headers/linux-libc-headers
14 gtk+/gtk+
14 binutils/binutils-cross-sdk
13 xorg-lib/pixman
12 u-boot/u-boot
12 mozilla/firefox
11 networkmanager/networkmanager
11 gtk-webcore/midori
11 glibc/glibc-initial
10 xorg-xserver/xserver-xorg
10 xorg-driver/xf86-input-evdev
10 transmission/transmission
10 pango/pango
10 linux/linux-omap1
10 connman/connman
10 cairo/cairo
10 bluez/bluez4
9 xorg-xserver/xserver-kdrive
9 xorg-lib/libx11
9 xorg-app/xinit
9 rxvt-unicode/rxvt-unicode
9 freetype/freetype
9 evince/evince
9 busybox/busybox
8 xorg-lib/libx11-native
8 xorg-driver/xf86-video-nv
8 wpa-supplicant/wpa-supplicant
8 telepathy/empathy
8 nautilus/nautilus
8 matchbox-panel/matchbox-panel
8 linux/linux-ixp4xx
8 libgpepimc/libgpepimc
8 intltool/intltool
8 gpe-todo/gpe-todo
8 gpe-mini-browser/gpe-mini-browser
8 gpe-clock/gpe-clock
8 gnome/libgsf
8 gnome/libgnomeui
8 gnome/libgnome
8 gnome/gnome-keyring
8 gnome/gnome-desktop
8 glib-2.0/glib-2.0-native
8 gimp/gimp
8 directfb/directfb
8 apt/apt
8 alsa/alsa-utils
8 alsa/alsa-lib
8 abiword/abiword
7 xorg-util/util-macros-native
7 xorg-util/util-macros
7 xorg-proto/inputproto
7 xorg-lib/xtrans
7 xorg-lib/libxfont
7 xorg-driver/xf86-video-geode
7 xorg-driver/xf86-input-mouse
7 udev/udev
7 uclibc/uclibc-initial
7 uclibc/uclibc
7 pulseaudio/pulseaudio
7 openvpn/openvpn
7 openssh/openssh
7 minilite/minilite
7 mesa/mesa
7 lirc/lirc-modules
7 linux/linux-omap
7 linux/linux-handhelds-2.6
7 libtool/libtool
7 libeventdb/libeventdb
7 intltool/intltool-native
7 hal/hal
7 gphoto2/gphoto2
7 gpe-what/gpe-what
7 gpe-ownerinfo/gpe-ownerinfo
7 gpe-conf/gpe-conf
7 gpe-bluetooth/gpe-bluetooth
7 gnome/libsoup-2.4
7 gnome/gnome-panel
7 gnome/gnome-menus
7 gnome/epiphany
7 e2fsprogs-libs/e2fsprogs-libs
7 avahi/avahi
6 xorg-proto/xproto-native
6 xorg-proto/xproto
6 xorg-lib/libxi
6 xorg-driver/xf86-video-vmware
6 xorg-driver/xf86-video-i128
6 xorg-driver/xf86-video-ati
6 xorg-driver/xf86-input-keyboard
6 xorg-app/xdm
6 xcb/xcb-proto
6 xcb/libxcb
6 tzdata/tzdata
6 scummvm/scummvm
6 poppler/poppler
6 patchutils/patchutils
6 mesa/mesa-dri
6 libxsettings-client/libxsettings-client
6 libtool/libtool-native
6 libtool/libtool-cross
6 libtododb/libtododb
6 libgpevtype/libgpevtype
6 libglade/libglade
6 kexecboot/linux-kexecboot
6 hal/hal-info
6 gphoto2/libgphoto2
6 gpephone/gpe-applauncher
6 gpe-filemanager/gpe-filemanager
6 gnome/libgnomecanvas
6 gnash/gnash
6 gdb/gdb-cross
6 gdb/gdb
6 freetype/freetype-native
6 fontconfig/fontconfig
6 ekiga/ptlib
6 ekiga/opal
6 ekiga/ekiga
6 dri/libdrm
6 devio/devio-native
6 devio/devio
6 asterisk/asterisk
6 apt/apt-native
6 acpid/acpid
6 abiword/abiword-plugins
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [RFC] duplicate recipes 2010-02-28 20:01 [RFC] duplicate recipes Frans Meulenbroeks @ 2010-02-28 20:06 ` Koen Kooi 2010-02-28 21:37 ` Michael 'Mickey' Lauer ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Koen Kooi @ 2010-02-28 20:06 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 See my response to your glib proposal On 28-02-10 21:01, Frans Meulenbroeks wrote: > Below is a list of all recipes that have 5 or more versions. > Guess a lot of these are deadwood. > Proposal is to do some cleaning for these. > > Probably the best scenario is to remove all versions which > - are not the latest version > - are not pinned with PREFERRED_VERSION in conf/distro/* > - do not have the largest DEFAULT_PREFERENCE > > What do people feel about this? > > Frans. > > 26 glib-2.0/glib-2.0 > 26 gcc/gcc-cross > 25 gcc/gcc-cross-intermediate > 25 gcc/gcc-cross-initial > 25 gcc/gcc > 24 linux/linux > 22 binutils/binutils-cross > 22 binutils/binutils > 18 gcc/gcc-cross-sdk > 16 glibc/glibc > 15 xserver-common/xserver-common > 14 linux-libc-headers/linux-libc-headers > 14 gtk+/gtk+ > 14 binutils/binutils-cross-sdk > 13 xorg-lib/pixman > 12 u-boot/u-boot > 12 mozilla/firefox > 11 networkmanager/networkmanager > 11 gtk-webcore/midori > 11 glibc/glibc-initial > 10 xorg-xserver/xserver-xorg > 10 xorg-driver/xf86-input-evdev > 10 transmission/transmission > 10 pango/pango > 10 linux/linux-omap1 > 10 connman/connman > 10 cairo/cairo > 10 bluez/bluez4 > 9 xorg-xserver/xserver-kdrive > 9 xorg-lib/libx11 > 9 xorg-app/xinit > 9 rxvt-unicode/rxvt-unicode > 9 freetype/freetype > 9 evince/evince > 9 busybox/busybox > 8 xorg-lib/libx11-native > 8 xorg-driver/xf86-video-nv > 8 wpa-supplicant/wpa-supplicant > 8 telepathy/empathy > 8 nautilus/nautilus > 8 matchbox-panel/matchbox-panel > 8 linux/linux-ixp4xx > 8 libgpepimc/libgpepimc > 8 intltool/intltool > 8 gpe-todo/gpe-todo > 8 gpe-mini-browser/gpe-mini-browser > 8 gpe-clock/gpe-clock > 8 gnome/libgsf > 8 gnome/libgnomeui > 8 gnome/libgnome > 8 gnome/gnome-keyring > 8 gnome/gnome-desktop > 8 glib-2.0/glib-2.0-native > 8 gimp/gimp > 8 directfb/directfb > 8 apt/apt > 8 alsa/alsa-utils > 8 alsa/alsa-lib > 8 abiword/abiword > 7 xorg-util/util-macros-native > 7 xorg-util/util-macros > 7 xorg-proto/inputproto > 7 xorg-lib/xtrans > 7 xorg-lib/libxfont > 7 xorg-driver/xf86-video-geode > 7 xorg-driver/xf86-input-mouse > 7 udev/udev > 7 uclibc/uclibc-initial > 7 uclibc/uclibc > 7 pulseaudio/pulseaudio > 7 openvpn/openvpn > 7 openssh/openssh > 7 minilite/minilite > 7 mesa/mesa > 7 lirc/lirc-modules > 7 linux/linux-omap > 7 linux/linux-handhelds-2.6 > 7 libtool/libtool > 7 libeventdb/libeventdb > 7 intltool/intltool-native > 7 hal/hal > 7 gphoto2/gphoto2 > 7 gpe-what/gpe-what > 7 gpe-ownerinfo/gpe-ownerinfo > 7 gpe-conf/gpe-conf > 7 gpe-bluetooth/gpe-bluetooth > 7 gnome/libsoup-2.4 > 7 gnome/gnome-panel > 7 gnome/gnome-menus > 7 gnome/epiphany > 7 e2fsprogs-libs/e2fsprogs-libs > 7 avahi/avahi > 6 xorg-proto/xproto-native > 6 xorg-proto/xproto > 6 xorg-lib/libxi > 6 xorg-driver/xf86-video-vmware > 6 xorg-driver/xf86-video-i128 > 6 xorg-driver/xf86-video-ati > 6 xorg-driver/xf86-input-keyboard > 6 xorg-app/xdm > 6 xcb/xcb-proto > 6 xcb/libxcb > 6 tzdata/tzdata > 6 scummvm/scummvm > 6 poppler/poppler > 6 patchutils/patchutils > 6 mesa/mesa-dri > 6 libxsettings-client/libxsettings-client > 6 libtool/libtool-native > 6 libtool/libtool-cross > 6 libtododb/libtododb > 6 libgpevtype/libgpevtype > 6 libglade/libglade > 6 kexecboot/linux-kexecboot > 6 hal/hal-info > 6 gphoto2/libgphoto2 > 6 gpephone/gpe-applauncher > 6 gpe-filemanager/gpe-filemanager > 6 gnome/libgnomecanvas > 6 gnash/gnash > 6 gdb/gdb-cross > 6 gdb/gdb > 6 freetype/freetype-native > 6 fontconfig/fontconfig > 6 ekiga/ptlib > 6 ekiga/opal > 6 ekiga/ekiga > 6 dri/libdrm > 6 devio/devio-native > 6 devio/devio > 6 asterisk/asterisk > 6 apt/apt-native > 6 acpid/acpid > 6 abiword/abiword-plugins -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFLisy0MkyGM64RGpERArWXAJ43bzx4SWyy04pwtkcpFIZ8uSSnmQCfTyKH 4EDGu96D7EEXz+bzVyDLSUY= =tHHd -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-02-28 20:01 [RFC] duplicate recipes Frans Meulenbroeks 2010-02-28 20:06 ` Koen Kooi @ 2010-02-28 21:37 ` Michael 'Mickey' Lauer 2010-02-28 21:48 ` Philip Balister 2010-02-28 22:10 ` Graeme Gregory 3 siblings, 0 replies; 12+ messages in thread From: Michael 'Mickey' Lauer @ 2010-02-28 21:37 UTC (permalink / raw) To: openembedded-devel Am Sonntag, den 28.02.2010, 21:01 +0100 schrieb Frans Meulenbroeks: > Below is a list of all recipes that have 5 or more versions. > Guess a lot of these are deadwood. > Proposal is to do some cleaning for these. > > Probably the best scenario is to remove all versions which > - are not the latest version > - are not pinned with PREFERRED_VERSION in conf/distro/* > - do not have the largest DEFAULT_PREFERENCE > > What do people feel about this? As written in your other mail, moving them out of sight (even perhaps in an own repository) would have my support. -- :M: ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-02-28 20:01 [RFC] duplicate recipes Frans Meulenbroeks 2010-02-28 20:06 ` Koen Kooi 2010-02-28 21:37 ` Michael 'Mickey' Lauer @ 2010-02-28 21:48 ` Philip Balister 2010-02-28 22:10 ` Graeme Gregory 3 siblings, 0 replies; 12+ messages in thread From: Philip Balister @ 2010-02-28 21:48 UTC (permalink / raw) To: openembedded-devel On 02/28/2010 03:01 PM, Frans Meulenbroeks wrote: > Below is a list of all recipes that have 5 or more versions. > Guess a lot of these are deadwood. > Proposal is to do some cleaning for these. > > Probably the best scenario is to remove all versions which > - are not the latest version > - are not pinned with PREFERRED_VERSION in conf/distro/* > - do not have the largest DEFAULT_PREFERENCE > > What do people feel about this? No, as noted elsewhere we have no idea who might be using older versions. In general, I support people who are actively involved in specific recipes, who are familiar with the user base of the recipe in cleaning up recipes (including removing old recipes) I do not support cleaning up recipes for the sake of "cleaning up". Philip > > Frans. > > 26 glib-2.0/glib-2.0 > 26 gcc/gcc-cross > 25 gcc/gcc-cross-intermediate > 25 gcc/gcc-cross-initial > 25 gcc/gcc > 24 linux/linux > 22 binutils/binutils-cross > 22 binutils/binutils > 18 gcc/gcc-cross-sdk > 16 glibc/glibc > 15 xserver-common/xserver-common > 14 linux-libc-headers/linux-libc-headers > 14 gtk+/gtk+ > 14 binutils/binutils-cross-sdk > 13 xorg-lib/pixman > 12 u-boot/u-boot > 12 mozilla/firefox > 11 networkmanager/networkmanager > 11 gtk-webcore/midori > 11 glibc/glibc-initial > 10 xorg-xserver/xserver-xorg > 10 xorg-driver/xf86-input-evdev > 10 transmission/transmission > 10 pango/pango > 10 linux/linux-omap1 > 10 connman/connman > 10 cairo/cairo > 10 bluez/bluez4 > 9 xorg-xserver/xserver-kdrive > 9 xorg-lib/libx11 > 9 xorg-app/xinit > 9 rxvt-unicode/rxvt-unicode > 9 freetype/freetype > 9 evince/evince > 9 busybox/busybox > 8 xorg-lib/libx11-native > 8 xorg-driver/xf86-video-nv > 8 wpa-supplicant/wpa-supplicant > 8 telepathy/empathy > 8 nautilus/nautilus > 8 matchbox-panel/matchbox-panel > 8 linux/linux-ixp4xx > 8 libgpepimc/libgpepimc > 8 intltool/intltool > 8 gpe-todo/gpe-todo > 8 gpe-mini-browser/gpe-mini-browser > 8 gpe-clock/gpe-clock > 8 gnome/libgsf > 8 gnome/libgnomeui > 8 gnome/libgnome > 8 gnome/gnome-keyring > 8 gnome/gnome-desktop > 8 glib-2.0/glib-2.0-native > 8 gimp/gimp > 8 directfb/directfb > 8 apt/apt > 8 alsa/alsa-utils > 8 alsa/alsa-lib > 8 abiword/abiword > 7 xorg-util/util-macros-native > 7 xorg-util/util-macros > 7 xorg-proto/inputproto > 7 xorg-lib/xtrans > 7 xorg-lib/libxfont > 7 xorg-driver/xf86-video-geode > 7 xorg-driver/xf86-input-mouse > 7 udev/udev > 7 uclibc/uclibc-initial > 7 uclibc/uclibc > 7 pulseaudio/pulseaudio > 7 openvpn/openvpn > 7 openssh/openssh > 7 minilite/minilite > 7 mesa/mesa > 7 lirc/lirc-modules > 7 linux/linux-omap > 7 linux/linux-handhelds-2.6 > 7 libtool/libtool > 7 libeventdb/libeventdb > 7 intltool/intltool-native > 7 hal/hal > 7 gphoto2/gphoto2 > 7 gpe-what/gpe-what > 7 gpe-ownerinfo/gpe-ownerinfo > 7 gpe-conf/gpe-conf > 7 gpe-bluetooth/gpe-bluetooth > 7 gnome/libsoup-2.4 > 7 gnome/gnome-panel > 7 gnome/gnome-menus > 7 gnome/epiphany > 7 e2fsprogs-libs/e2fsprogs-libs > 7 avahi/avahi > 6 xorg-proto/xproto-native > 6 xorg-proto/xproto > 6 xorg-lib/libxi > 6 xorg-driver/xf86-video-vmware > 6 xorg-driver/xf86-video-i128 > 6 xorg-driver/xf86-video-ati > 6 xorg-driver/xf86-input-keyboard > 6 xorg-app/xdm > 6 xcb/xcb-proto > 6 xcb/libxcb > 6 tzdata/tzdata > 6 scummvm/scummvm > 6 poppler/poppler > 6 patchutils/patchutils > 6 mesa/mesa-dri > 6 libxsettings-client/libxsettings-client > 6 libtool/libtool-native > 6 libtool/libtool-cross > 6 libtododb/libtododb > 6 libgpevtype/libgpevtype > 6 libglade/libglade > 6 kexecboot/linux-kexecboot > 6 hal/hal-info > 6 gphoto2/libgphoto2 > 6 gpephone/gpe-applauncher > 6 gpe-filemanager/gpe-filemanager > 6 gnome/libgnomecanvas > 6 gnash/gnash > 6 gdb/gdb-cross > 6 gdb/gdb > 6 freetype/freetype-native > 6 fontconfig/fontconfig > 6 ekiga/ptlib > 6 ekiga/opal > 6 ekiga/ekiga > 6 dri/libdrm > 6 devio/devio-native > 6 devio/devio > 6 asterisk/asterisk > 6 apt/apt-native > 6 acpid/acpid > 6 abiword/abiword-plugins > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-02-28 20:01 [RFC] duplicate recipes Frans Meulenbroeks ` (2 preceding siblings ...) 2010-02-28 21:48 ` Philip Balister @ 2010-02-28 22:10 ` Graeme Gregory 2010-03-01 7:28 ` Frans Meulenbroeks 3 siblings, 1 reply; 12+ messages in thread From: Graeme Gregory @ 2010-02-28 22:10 UTC (permalink / raw) To: openembedded-devel On Sun, Feb 28, 2010 at 09:01:45PM +0100, Frans Meulenbroeks wrote: > Below is a list of all recipes that have 5 or more versions. > Guess a lot of these are deadwood. > Proposal is to do some cleaning for these. > > Probably the best scenario is to remove all versions which > - are not the latest version > - are not pinned with PREFERRED_VERSION in conf/distro/* > - do not have the largest DEFAULT_PREFERENCE > > What do people feel about this? > If you search back in the list this question is asked once every 6 months ago and the discussion always ends the same. We dont need to blindly delete old recipes. Now on to important issues. If people are looking for something to keep them busy then there are two important tasks that need to be completed in OE one of them saves hours on build times, the other makes parsing quicker. Convert as many -native recipes to BBCLASSEXTEND as possible. Poky has lots of them done already so this is as simple as copy and test. Convert recipes to new staging. There have been numerous posts on the list lately detailing how to do this. This one saves hours in build time. Graeme ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-02-28 22:10 ` Graeme Gregory @ 2010-03-01 7:28 ` Frans Meulenbroeks 2010-03-10 15:44 ` Frans Meulenbroeks 0 siblings, 1 reply; 12+ messages in thread From: Frans Meulenbroeks @ 2010-03-01 7:28 UTC (permalink / raw) To: openembedded-devel 2010/2/28 Graeme Gregory <dp@xora.org.uk>: > Now on to important issues. > > If people are looking for something to keep them busy then there are two > important tasks that need to be completed in OE one of them saves hours > on build times, the other makes parsing quicker. > > Convert as many -native recipes to BBCLASSEXTEND as possible. Poky has lots > of them done already so this is as simple as copy and test. I think BBCLASSEXTEND is very useful. However last time I tried (2-3 weeks ago) there were still issues with BBCLASSEXTEND and packaged staging. Never really got the time yet to dig into it (and also it is quite time-consuming to create a faulty situation). Also I've no idea on how to actually verify that the change is ok and blindly adding BBCLASSEXTEND = "native" and removing the -native recipe does not seem wise either. > > Convert recipes to new staging. There have been numerous posts on the list > lately detailing how to do this. This one saves hours in build time. Have you tried to do it according to the instructions? If you want to do it according to the instructions given it takes quite some time per recipe. Also if you do one thing, it does not say you should not do the other. I'd say it could be an and-and situation. Furthermore by cleaning up the recipes it is clear where things need to be done (so we avoid that someone wastes time on a recipe that is outdated/obsolete anyway). (and removing an obsolete recipe + native variant improves the parsing time twice as much as BBCLASSEXTEND-ing it). FM ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-03-01 7:28 ` Frans Meulenbroeks @ 2010-03-10 15:44 ` Frans Meulenbroeks 2010-03-10 16:01 ` Martin Jansa 2010-03-10 22:06 ` Graham Gower 0 siblings, 2 replies; 12+ messages in thread From: Frans Meulenbroeks @ 2010-03-10 15:44 UTC (permalink / raw) To: openembedded-devel Time for a summary I guess: original proposal from me: Probably the best scenario is to remove all versions which - are not the latest version - are not pinned with PREFERRED_VERSION in conf/distro/* - do not have the largest DEFAULT_PREFERENCE opinions: Koen: see glib proposal Mickey: move out of sight or own repo would have my support Philip: no as we do not know who is using the older versions Graeme: expressed that there are more important tasks to be done and in the glib-2.0 cleanup thread: koen: suggests to clean up after improving the recipes and prefers to move recipe to obsolete instead of delete it mickey: move out of sight graham: comes with more offending case, no opinion on the proposal given Marcin (on the gcc stuff: "If someone wants one then we have SCM for it." [note from FM: not sure if this a specific remark on the gcc debian patches or a generic statement] khem: moving to recipes/obsolete may not be so bad Denys: +1 (we already have recipes/obsolete in BBMASK, reduces parse time, git-mv does preserve history) and in the recipes/${distro} thread there were also a few comments on this. Most of these are from the same persons as mentioned above. Only addition that is related to this thread is: otavio: in favour of removing (faster parsing) Seems most people are in favour of remving out of sight: Counting head's for that variant (assuming that people wo stated that removal is the best choice are not against moving to an obsolete dir). in favour: frans, mickey, khem, denys, otavio and perhaps marcin against: koen, philip I've ocunted graeme as neutral and graham as no opinion given. If you feel I misrepresented your position or if I missed your position, feel free to follow up. Best regards, frans (ps: i expect that this concerns some 2000 recipes (out of 8000)) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-03-10 15:44 ` Frans Meulenbroeks @ 2010-03-10 16:01 ` Martin Jansa 2010-03-10 20:29 ` Frans Meulenbroeks 2010-03-10 22:06 ` Graham Gower 1 sibling, 1 reply; 12+ messages in thread From: Martin Jansa @ 2010-03-10 16:01 UTC (permalink / raw) To: openembedded-devel On Wed, Mar 10, 2010 at 04:44:48PM +0100, Frans Meulenbroeks wrote: > Time for a summary I guess: > > original proposal from me: > Probably the best scenario is to remove all versions which > - are not the latest version > - are not pinned with PREFERRED_VERSION in conf/distro/* > - do not have the largest DEFAULT_PREFERENCE I think this rules are quite strict, in first iteration would be enough to keep only latest from each "major" version where major version is defined by common-sense (ie first 2 version number for xorg, but somewhere first number is enough) ie for xserver-xorg: ../dev/recipes/xorg-xserver/xserver-xorg_1.2.0.bb ../dev/recipes/xorg-xserver/xserver-xorg_1.3.0.0.bb ../dev/recipes/xorg-xserver/xserver-xorg_1.4.2.bb mv ../dev/recipes/xorg-xserver/xserver-xorg_1.4.bb mv ../dev/recipes/xorg-xserver/xserver-xorg_1.5.1.bb ../dev/recipes/xorg-xserver/xserver-xorg_1.5.3.bb mv ../dev/recipes/xorg-xserver/xserver-xorg_1.7.1.bb ../dev/recipes/xorg-xserver/xserver-xorg_1.7.4.bb and update preferred-xorg-versions (1.7.1->1.7.4) and other if needed > opinions: JaMa: move older minor versions to obsolete, keep latest for each "major" -- uin:136542059 jid:Martin.Jansa@gmail.com Jansa Martin sip:jamasip@voip.wengo.fr JaMa ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-03-10 16:01 ` Martin Jansa @ 2010-03-10 20:29 ` Frans Meulenbroeks 2010-03-11 5:10 ` Martin Jansa 0 siblings, 1 reply; 12+ messages in thread From: Frans Meulenbroeks @ 2010-03-10 20:29 UTC (permalink / raw) To: openembedded-devel 2010/3/10 Martin Jansa <martin.jansa@gmail.com>: > On Wed, Mar 10, 2010 at 04:44:48PM +0100, Frans Meulenbroeks wrote: >> Time for a summary I guess: >> >> original proposal from me: >> Probably the best scenario is to remove all versions which >> - are not the latest version >> - are not pinned with PREFERRED_VERSION in conf/distro/* >> - do not have the largest DEFAULT_PREFERENCE > > I think this rules are quite strict, in first iteration would be enough > to keep only latest from each "major" version > > where major version is defined by common-sense (ie first 2 version > number for xorg, but somewhere first number is enough) > > ie for xserver-xorg: > ../dev/recipes/xorg-xserver/xserver-xorg_1.2.0.bb > ../dev/recipes/xorg-xserver/xserver-xorg_1.3.0.0.bb > ../dev/recipes/xorg-xserver/xserver-xorg_1.4.2.bb > mv ../dev/recipes/xorg-xserver/xserver-xorg_1.4.bb > mv ../dev/recipes/xorg-xserver/xserver-xorg_1.5.1.bb > ../dev/recipes/xorg-xserver/xserver-xorg_1.5.3.bb > mv ../dev/recipes/xorg-xserver/xserver-xorg_1.7.1.bb > ../dev/recipes/xorg-xserver/xserver-xorg_1.7.4.bb > > and update preferred-xorg-versions (1.7.1->1.7.4) and other if needed > >> opinions: > > JaMa: move older minor versions to obsolete, keep latest for each "major" Noted! (but for my understanding:why do you see it useful to retain old versions that are not pinned. For xorg, being a complicated and big thing I can partly understand it, but is there really a point in keeping old versions of e.g. transmission? (noting that if needed they can always be recovered from git). Frans ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-03-10 20:29 ` Frans Meulenbroeks @ 2010-03-11 5:10 ` Martin Jansa 0 siblings, 0 replies; 12+ messages in thread From: Martin Jansa @ 2010-03-11 5:10 UTC (permalink / raw) To: openembedded-devel On Wed, Mar 10, 2010 at 09:29:27PM +0100, Frans Meulenbroeks wrote: > 2010/3/10 Martin Jansa <martin.jansa@gmail.com>: > > On Wed, Mar 10, 2010 at 04:44:48PM +0100, Frans Meulenbroeks wrote: > >> Time for a summary I guess: > >> > >> original proposal from me: > >> Probably the best scenario is to remove all versions which > >> - are not the latest version > >> - are not pinned with PREFERRED_VERSION in conf/distro/* > >> - do not have the largest DEFAULT_PREFERENCE > > > > I think this rules are quite strict, in first iteration would be enough > > to keep only latest from each "major" version > > > > where major version is defined by common-sense (ie first 2 version > > number for xorg, but somewhere first number is enough) > > > > ie for xserver-xorg: > > ../dev/recipes/xorg-xserver/xserver-xorg_1.2.0.bb > > ../dev/recipes/xorg-xserver/xserver-xorg_1.3.0.0.bb > > ../dev/recipes/xorg-xserver/xserver-xorg_1.4.2.bb > > mv ../dev/recipes/xorg-xserver/xserver-xorg_1.4.bb > > mv ../dev/recipes/xorg-xserver/xserver-xorg_1.5.1.bb > > ../dev/recipes/xorg-xserver/xserver-xorg_1.5.3.bb > > mv ../dev/recipes/xorg-xserver/xserver-xorg_1.7.1.bb > > ../dev/recipes/xorg-xserver/xserver-xorg_1.7.4.bb > > > > and update preferred-xorg-versions (1.7.1->1.7.4) and other if needed > > > >> opinions: > > > > JaMa: move older minor versions to obsolete, keep latest for each "major" > > Noted! > > (but for my understanding:why do you see it useful to retain old > versions that are not pinned. For xorg, being a complicated and big > thing I can partly understand it, but is there really a point in Yes that's where I expect it could be difficult for some machine maintainer to jump from ie xserver-xorg-1.4.bb directly to 1.7.4, but moving to 1.4.2 should be quite painless. But I expect that that even removing some minor version of not so important xorg-app can create a bit work, as new one will need ie newer util-macros and newer util-macros maybe won't work with so old xserver etc. > keeping old versions of e.g. transmission? (noting that if needed they > can always be recovered from git). There is only one major version of transmission for me 1.x, so there would be only one latest. In most places it would be best to ask package maintainer / person who added most versions to do a cleanup or send him cleaning patch for ack. There is at least of latest versions with D_P -1 (and enabled for some distro) where is maybe D_P not needed anymore and can be removed. Regards, -- uin:136542059 jid:Martin.Jansa@gmail.com Jansa Martin sip:jamasip@voip.wengo.fr JaMa ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-03-10 15:44 ` Frans Meulenbroeks 2010-03-10 16:01 ` Martin Jansa @ 2010-03-10 22:06 ` Graham Gower 2010-03-11 20:13 ` Tom Rini 1 sibling, 1 reply; 12+ messages in thread From: Graham Gower @ 2010-03-10 22:06 UTC (permalink / raw) To: openembedded-devel On 11 March 2010 02:14, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote: > I've ocunted graeme as neutral and graham as no opinion given. > > If you feel I misrepresented your position or if I missed your > position, feel free to follow up. I didn't give an opinion because I'm not a committer and it probably doesn't count. But... I'm in favour of never seeing old recipes again unless there is a good reason (e.g. specific versions needed for specific boards). -Graham ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] duplicate recipes 2010-03-10 22:06 ` Graham Gower @ 2010-03-11 20:13 ` Tom Rini 0 siblings, 0 replies; 12+ messages in thread From: Tom Rini @ 2010-03-11 20:13 UTC (permalink / raw) To: openembedded-devel On Thu, 2010-03-11 at 08:36 +1030, Graham Gower wrote: > On 11 March 2010 02:14, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote: > > I've ocunted graeme as neutral and graham as no opinion given. > > > > If you feel I misrepresented your position or if I missed your > > position, feel free to follow up. > > I didn't give an opinion because I'm not a committer and it probably > doesn't count. But... I'm in favour of never seeing old recipes again > unless there is a good reason (e.g. specific versions needed for > specific boards). Also, for specific compatibilities (ie using OE to make stuff that's compatible with _____ spec or external distribution). -- Tom Rini <tom_rini@mentor.com> Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-03-11 20:17 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-02-28 20:01 [RFC] duplicate recipes Frans Meulenbroeks 2010-02-28 20:06 ` Koen Kooi 2010-02-28 21:37 ` Michael 'Mickey' Lauer 2010-02-28 21:48 ` Philip Balister 2010-02-28 22:10 ` Graeme Gregory 2010-03-01 7:28 ` Frans Meulenbroeks 2010-03-10 15:44 ` Frans Meulenbroeks 2010-03-10 16:01 ` Martin Jansa 2010-03-10 20:29 ` Frans Meulenbroeks 2010-03-11 5:10 ` Martin Jansa 2010-03-10 22:06 ` Graham Gower 2010-03-11 20:13 ` Tom Rini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.