2009/12/4 Jan Matějek :

Dne 4.12.2009 17:00, Rob OpenSuSE napsal(a):

...

2009/12/4 Jan Matejek :

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

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

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

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

2009/12/4 Stefan Seyfried :

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

On Sat, 5 Dec 2009 08:57:14 +0000 Rob OpenSuSE wrote:

2009/12/4 Stefan Seyfried :

...

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

2009/12/8 Joerg Schilling :

Stefan Seyfried 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