[opensuse-factory] dropping BitTorrent (Mainline) package
dear openSUSErs, for a long time we've been distributing the official BitTorrent (a.k.a. Mainline) client. And for some years we've been stuck with version 4.0.4, because we couldn't include DHT support (legal reasons). Now that it turns out that we can include DHT after all, it also turns out that mainline's source is closed since 2007 or something. There is still version 5.3 available under GPL, but i don't see much value in upgrading to version that is three years old. (and to be perfectly honest, i'm not even sure that our BitTorrent version still works) We now have better bittorrent clients for GUI (KTorrent, Transmission) as well as for console (rtorrent - not in the official distro, but can be found in OBS), so losing Mainline shouldn't be a problem. If you use bittorrent in headless environments, you might be interested in combining ncurses-based rtorrent with 'screen'. Deleterequest#25604 filed. May you rest in peace, BitTorrent. regards m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/4 Jan Matejek <jan.matejek@novell.com>:
If you use bittorrent in headless environments, you might be interested in combining ncurses-based rtorrent with 'screen'.
Does that have advantage over the transmission-daemon solution which seems to have remote GUI support as an option? I've been seeding torrents and wanted to move to headless, but not configured transmission yet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dne 4.12.2009 17:00, Rob OpenSuSE napsal(a):
2009/12/4 Jan Matejek <jan.matejek@novell.com>:
If you use bittorrent in headless environments, you might be interested in combining ncurses-based rtorrent with 'screen'.
Does that have advantage over the transmission-daemon solution which seems to have remote GUI support as an option? I've been seeding torrents and wanted to move to headless, but not configured transmission yet.
This was meant more like "if you're still using Mainline because of headless" alternative. I never used Transmission, so i didn't know about its headless capabilities. Possible advantage of rtorrent-in-screen setup is that you literally get the same experience you'd have on your desktop. If transmission-daemon can do that too, then it comes down to which client you like more. m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/4 Jan Matějek <jmatejek@suse.cz>:
Dne 4.12.2009 17:00, Rob OpenSuSE napsal(a):
2009/12/4 Jan Matejek <jan.matejek@novell.com>:
Does that have advantage over the transmission-daemon solution which seems to have remote GUI support as an option? I've been seeding torrents and wanted to move to headless, but not configured transmission yet.
This was meant more like "if you're still using Mainline because of headless" alternative. I never used Transmission, so i didn't know about its headless capabilities. Possible advantage of rtorrent-in-screen setup is that you literally get the same experience you'd have on your desktop. If transmission-daemon can do that too, then it comes down to which client you like more.
Thanks! I was interested in transmission as it was mentioned by Torrentfreak as an up & coming client with GUI & low memory usage daemon possibilities. http://trac.transmissionbt.com/ What interested me, was it looks like it's developed to cover seeding/download from servers by remote connection, as well as having selection of GUI clients, GTK, Qt in addition to web browser support. So it looked good fit for end users, willing to donate some seed upload bandwidth, whilst not requiring burden of GUI client running it does let one be used. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE wrote:
2009/12/4 Jan Matejek <jan.matejek@novell.com>:
If you use bittorrent in headless environments, you might be interested in combining ncurses-based rtorrent with 'screen'.
Does that have advantage over the transmission-daemon solution which seems to have remote GUI support as an option? I've been seeding torrents and wanted to move to headless,
Rob, look up btpd - I've been running that for about a year, it works really well. /Per -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 04/12/2009 16:25, Jan Matejek a écrit :
dear openSUSErs,
for a long time we've been distributing the official BitTorrent (a.k.a. Mainline) client. And for some years we've been stuck with version 4.0.4, because we couldn't include DHT support (legal reasons).
Now that it turns out that we can include DHT after all, it also turns out that mainline's source is closed since 2007 or something. There is still version 5.3 available under GPL, but i don't see much value in upgrading to version that is three years old. (and to be perfectly honest, i'm not even sure that our BitTorrent version still works)
We now have better bittorrent clients for GUI (KTorrent, Transmission) as well as for console (rtorrent - not in the official distro, but can be found in OBS), so losing Mainline shouldn't be a problem. If you use bittorrent in headless environments, you might be interested in combining ncurses-based rtorrent with 'screen'.
Deleterequest#25604 filed. May you rest in peace, BitTorrent.
regards m. could you replace the bittorrent package (removed) by a copy of this annoucement? just to make sure any people is informed (including people not reading this mailing list)
thanks jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Dec 04, 2009 at 07:00:14PM +0100, jdd wrote: [ 8< ]
could you replace the bittorrent package (removed) by a copy of this annoucement? just to make sure any people is informed (including people not reading this mailing list)
I consider this the wrong approach. Such information belongs to the list of dropped features/ packages available from the wiki. Even a separate section in the release notes of a new version might fit well. But keeping entries with pure meta information in the RPM DB would diminish it to some sort of trashcan. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Lars Müller wrote:
On Fri, Dec 04, 2009 at 07:00:14PM +0100, jdd wrote: [ 8< ]
could you replace the bittorrent package (removed) by a copy of this annoucement? just to make sure any people is informed (including people not reading this mailing list)
I consider this the wrong approach.
Such information belongs to the list of dropped features/ packages available from the wiki.
Even a separate section in the release notes of a new version might fit well.
But keeping entries with pure meta information in the RPM DB would diminish it to some sort of trashcan.
It might not be an entirely bad idea - when someone/newbie goes to search for <some package>, it could be quite helpful for him to get a result of "dropped due to .....". /Per -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Dec 04, 2009 at 07:54:11PM +0100, Per Jessen wrote:
Lars Müller wrote:
On Fri, Dec 04, 2009 at 07:00:14PM +0100, jdd wrote: [ 8< ]
could you replace the bittorrent package (removed) by a copy of this annoucement? just to make sure any people is informed (including people not reading this mailing list)
I consider this the wrong approach.
Such information belongs to the list of dropped features/ packages available from the wiki.
Even a separate section in the release notes of a new version might fit well.
But keeping entries with pure meta information in the RPM DB would diminish it to some sort of trashcan.
It might not be an entirely bad idea - when someone/newbie goes to search for <some package>, it could be quite helpful for him to get a result of "dropped due to .....".
Yes, but that might not require to keep a dummy package and might not be stored in the RPM DB. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Le 04/12/2009 19:59, Lars Müller a écrit :
Yes, but that might not require to keep a dummy package and might not be stored in the RPM DB.
and why? save 15 bytes? what is important is user convience, specially when it's a no work system jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Dec 04, 2009 at 08:54:16PM +0100, jdd wrote:
Le 04/12/2009 19:59, Lars Müller a écrit :
Yes, but that might not require to keep a dummy package and might not be stored in the RPM DB.
and why? save 15 bytes?
It does not belong to the package DB as it is no longer a package.
what is important is user convience, specially when it's a no work system
That's why I suggested to communicate the chnage via the release notes and or the wiki. BTW That is my point of view. If you consider this important for your convience please file a feature request. I'm for my part am happy if I get informed if discontinued stuff gets dropped. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Le 04/12/2009 21:11, Lars Müller a écrit :
On Fri, Dec 04, 2009 at 08:54:16PM +0100, jdd wrote:
I'm for my part am happy if I get informed if discontinued stuff gets dropped.
yes, that is the main point. May be a package 'discontinued' with the advices for all discontinued packages... it's only important to have the info at the moment one try to use the lacking package. May be in YaST wiki or network is now handy at this point jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 4 Dec 2009 21:11:03 +0100 Lars Müller <lmuelle@suse.de> wrote:
On Fri, Dec 04, 2009 at 08:54:16PM +0100, jdd wrote:
Le 04/12/2009 19:59, Lars Müller a écrit :
Yes, but that might not require to keep a dummy package and might not be stored in the RPM DB.
and why? save 15 bytes?
It does not belong to the package DB as it is no longer a package.
And it will screw up stuff like dependencies etc. and make everything slower. But the repository metadata could have an extra file with no-longer-present packages, which would only be consulted if e.g. "zypper search" finds out that the package is not available. It could even be used to point to alternate repositories etc... Have fun, seife -- Stefan Seyfried I don't know why I dream this way The sky is purple and things are right every day I don't know, it's just this world's so far away But I won't fight, and I won't hate / Well not today -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/4 Stefan Seyfried <stefan.seyfried@googlemail.com>:
And it will screw up stuff like dependencies etc. and make everything slower.
But the repository metadata could have an extra file with no-longer-present packages, which would only be consulted if e.g. "zypper search" finds out that the package is not available. It could even be used to point to alternate repositories etc...
To me the package management has enough work, managing the current packages in repo's without having cruft of discontinued packages accreting gradually in future releases. It may be confusing to have packages listed, that are actually not installable. Having such would likely mean requests to have "discontinued" & "active" filter in YaST Software Manager. Traditionally this is kind of thing you expect to find in the Release Notes, but that has never been especially effective. Now there's a utility been introduced "cnf" to report information to the user who can query missing commands, it validates PATH and searches in package repo. Couldn't it also search in a DB of "discontinued" of dropped files and package names, and return summary info, suggested alternative and URL to the drop announcement web page which has the rationale? Keeps the information "out of band" and in a non-critical part of the system. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 05/12/2009 09:57, Rob OpenSuSE a écrit :
Now there's a utility been introduced "cnf" to report information to the user who can query missing commands, it validates PATH and searches in package repo. Couldn't it also search in a DB of "discontinued" of dropped files and package names, and return summary info, suggested alternative and URL to the drop announcement web page which has the rationale?
Keeps the information "out of band" and in a non-critical part of the system.
that would be very smart jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 5 Dec 2009 08:57:14 +0000 Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
2009/12/4 Stefan Seyfried <stefan.seyfried@googlemail.com>:
But the repository metadata could have an extra file with no-longer-present packages, which would only be consulted if e.g. "zypper search" finds out that the package is not available. It could even be used to point to alternate repositories etc...
To me the package management has enough work, managing the current
Agreed. That's why I suggested having it in an extra file (but probably part of the repo metadata, to be able to keep it up-to-date with the rest of the system) that would only be queried if the solver decides that he cannot find a package. It would not slow down the resolver etc, since the data would not even be loaded in memory at that time. And of course the feature could be trivially easy be turned off.
packages in repo's without having cruft of discontinued packages accreting gradually in future releases. It may be confusing to have packages listed, that are actually not installable. Having such would likely mean requests to have "discontinued" & "active" filter in YaST Software Manager.
They would not be listed. Only if you would search for, say, "yacc", it would point you to "bison". (Phew, avoided the cdr<censored> example ;) Maybe also command-not-found could query this database.
Traditionally this is kind of thing you expect to find in the Release Notes, but that has never been especially effective.
Yes, and to be honest, I am not reading hte release notes that often (because I always run FACTORY), but I still would find such a feature useful.
Now there's a utility been introduced "cnf" to report information to the user who can query missing commands, it validates PATH and searches in package repo. Couldn't it also search in a DB of "discontinued" of dropped files and package names, and return summary info, suggested alternative and URL to the drop announcement web page which has the rationale?
Keeps the information "out of band" and in a non-critical part of the system.
Oops, we roughly had the same idea ;) If it only shows up in cnf or also in "zypper search -> not found" is basically an implementation detail. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
They would not be listed. Only if you would search for, say, "yacc", it would point you to "bison". (Phew, avoided the cdr<censored> example ;)
There is a significant difference: "bison" is an independent development ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/8 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
They would not be listed. Only if you would search for, say, "yacc", it would point you to "bison". (Phew, avoided the cdr<censored> example ;)
There is a significant difference: "bison" is an independent development ;-)
Hmmmm... http://invisible-island.net/byacc/byacc.html HISTORY Byacc was written around 1990 by Robert Corbett who is the original author of bison. Originally written in K&R C, I have modified it to conform to ANSI C, and made other improvements. See the changelog for details. If we look at http://byaccj.sourceforge.net/ you see byacc is called "yacc" (same command name) as AT&T yacc for compatibility reasons. If we go back to AT&T then /bin/sh original was replaced by Bourne shell, cc got replaced by pcc, and kept the cc(1) name, lots and lots of precedent for avoiding breaking tool chains when replacing components with new implementations. Anyone heard Ken & Dennis complaining that GNU have re-used the name of ls(1), grep(1) etc? Even in the 90's it was common to upgrade Sun's Solaris yacc, and provide a cc from 3rd party. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stefan Seyfried wrote:
On Fri, 4 Dec 2009 21:11:03 +0100 Lars Müller <lmuelle@suse.de> wrote:
On Fri, Dec 04, 2009 at 08:54:16PM +0100, jdd wrote:
Le 04/12/2009 19:59, Lars Müller a écrit :
Yes, but that might not require to keep a dummy package and might not be stored in the RPM DB.
and why? save 15 bytes?
It does not belong to the package DB as it is no longer a package.
And it will screw up stuff like dependencies etc. and make everything slower.
But the repository metadata could have an extra file with no-longer-present packages, which would only be consulted if e.g. "zypper search" finds out that the package is not available. It could even be used to point to alternate repositories etc...
Sounds like a pretty good idea. /Per -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (8)
-
Jan Matejek -
Jan Matějek -
jdd -
Joerg.Schilling＠fokus.fraunhofer.de -
Lars Müller -
Per Jessen -
Rob OpenSuSE -
Stefan Seyfried