On Tuesday 16 October 2007 17:57, Scott Kitterman wrote: > On Tuesday 16 October 2007 17:27, João Pinto wrote: > > Hello, > > I am not going to touch the gnucash package because the "Feisty" getdeb > > archive is frozen. > > When a new release arrives, we also get a frozen archive, on our case, > > for the past release. > > > > Still, you can request it's removal by reporting is as a bug at: > > https://launchpad.net/getdeb.net/ > > > > If we believe there is a good reason for an exception, the package will > > be removed. > > OK. Well then I guess already in an Ubuntu archive isn't a good reason > (you don't need me to write a bug report for that as you already know).
On Tuesday 16 October 2007 19:06, Krzysztof Lichota wrote: > Backports is sometimes not a proper solution, because it causes upgrade > to all the newest versions of a lot of packages. For example, if user > wants to upgrade amarok but not kopete, he can do it using GetDeb, but > he cannot do it using backports (forget package pinning/repository > priorities, it is in no way intuitive and cannot be done by "average > users"). I was thinking about this some more. My objection isn't to the installation method, but to the packages. Someone earlier in the thread mentioned the benifits of the web front end that Getdeb provides. Rather than remove something like gnucash from getdeb, what really needs to happen is just pointint from the getdeb package to the Ubuntu one. In the gnucash case it would be changing: http://www.getdeb.net/download.php?release=1496&fpos=0 http://www.getdeb.net/download.php?release=1496&fpos=1 http://www.getdeb.net/download.php?release=1496&fpos=2 with http://launchpadlibrarian.net/9958499/gnucash_2.2.1-1ubuntu4%7Efeisty1_i386.deb http://launchpadlibrarian.net/9958498/gnucash-common_2.2.1-1ubuntu4%7Efeisty1_all.deb http://launchpadlibrarian.net/9959217/gnucash-docs_2.2.0-1%7Efeisty1_all.deb The web front end could stay. This would have a number of advantages: Reduced storage and bandwidth usage for getdeb Fewer packages users have to uninstall before an upgrade Fewer issues due to unofficial package use How about something like that? I've no objections to that approach myself. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
