repository recommendations

[BriGy86]

one example: I am using Suse 10.2 and I wanted to download Kismet.

right now all I have are the download.opensuse repositories

I then tried to Google a repository that had kismet in it and didn't have a lot of luck with the small amount of time I spent

I did find an ubuntu one that says they have it but I'm assuming that wont work since I am using RPM's

so I was thinking that people may be able to list which ones they have as well as what install of Linux they're using or what kind package management they are using.

might make searches in the future faster for the rest of us.

Here is one I used for my Nvidia 7600 video card
http://download.nvidia.com/opensuse/10.2

Here are the Suse ones I have. (They come with the installation)
http://download.opensuse.org/d...ion/10.2/repo/non-oss/
http://download.opensuse.org/d...ibution/10.2/repo/oss/
http://download.opensuse.org/d...ution/10.2/repo/debug/

 

[Nothinman]

I stick with the official repos as much as possible because trusting a repo opens your system up to all kinds of attacks and problems since all package installations are done as root. Even if the repo is maintained by a trustworthy person package quality varies a lot since 3rd party packages aren't subject to the same QA as official packages. That's the nice thing about Debian (and to an extent Ubuntu), just about everything I want is packaged in main. The only 3rd party repo I use, http://www.debian-multimedia.org/, is also maintained by a Debian developer so I'm not worried about any problems there.

 

[Brazen]

Save yourself a lot of headaches and use a better linux distro. I would suggest Debian on a server, or Ubuntu on a desktop.

 

[BriGy86]

Originally posted by: Brazen
Save yourself a lot of headaches and use a better linux distro. I would suggest Debian on a server, or Ubuntu on a desktop.

I found that it's easier to install things that require the gui not to be running. unless you edit the inittab file to change what run level does what

 

[SleepWalkerX]

You should add guru and packman. Kismet can be found in the second repository you listed. Smart is the best package manager I've come across. I like it better than apt.

packman: http://packman.inode.at/suse/10.2
guru: ftp://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.2

 

[Nothinman]

Smart is the best package manager I've come across. I like it better than apt.

Why?

 

[SleepWalkerX]

1) I don't need to read the documentation to use it. It makes sense. Say I want to search for something? Smart search something. Simple. What about apt? I had to look forever online to find out that its a totally different command than apt-get. Why not have it unified around, let's say, an apt command? Apt get package or apt search package? It makes much more sense. Personal nitpick.

2) Parallel downloads

3) It has a pretty sweet system for handling mirrors. It'll detect which mirror is the "fastest" and use it.

4) Priority handling

5) I can keep the same package manager I'm familiar with on most major distros.

6) Apparently there are a few examples where the smart's package management does a "better" job of handling dependencies than apt or yum. Not sure if this is still an issue with apt, but its nice to know smart was developed with dependency issues like these in mind.

http://zorked.net/smart/doc/README.html#study-cases

 

[Brazen]

IIRC, Smart is even developed by the same person who started apt. So basically Smart is a rewrite to fix all the mistakes the developer feels he did the first go around with apt. With that said, personally I like aptitude or yum.

 

[Nothinman]

1) I don't need to read the documentation to use it. It makes sense. Say I want to search for something? Smart search something. Simple. What about apt? I had to look forever online to find out that its a totally different command than apt-get. Why not have it unified around, let's say, an apt command? Apt get package or apt search package? It makes much more sense. Personal nitpick.

That's fine, but the apt-* commands were originally for debugging only and users were supposed to use things like dselect, aptitutde and synaptic.

2) Parallel downloads

Apt does parallel downloads to separate repositories, not sure if you can configure it to do them to the same repo but most site owners would probably consider that bad anyway.

3) It has a pretty sweet system for handling mirrors. It'll detect which mirror is the "fastest" and use it.

You can use apt-mirror to bandwidth test and pick a mirror, but I've never had the main Debian mirrors not go as fast as my cable will allow.

4) Priority handling

Huh?

5) I can keep the same package manager I'm familiar with on most major distros.

The only distros I'm really concerned about are Debian and RHEL and I doubt RH will support me if I use smart.

6) Apparently there are a few examples where the smart's package management does a "better" job of handling dependencies than apt or yum. Not sure if this is still an issue with apt, but its nice to know smart was developed with dependency issues like these in mind.

I use aptitude most of the time which handles dependencies just fine, it even offers you a list of solutions and lets you pick which one you want to use.

 

[SleepWalkerX]

Do you like arguing for the sake of arguing?

Originally posted by: Nothinman

2) Parallel downloads

Apt does parallel downloads to separate repositories, not sure if you can configure it to do them to the same repo but most site owners would probably consider that bad anyway.

Mirrors.

Originally posted by: Nothinman

3) It has a pretty sweet system for handling mirrors. It'll detect which mirror is the "fastest" and use it.

You can use apt-mirror to bandwidth test and pick a mirror, but I've never had the main Debian mirrors not go as fast as my cable will allow.

Its nice to have that built-in to where you don't have to test the bandwidth of each repo/mirror before using it.

Originally posted by: Nothinman

4) Priority handling

Huh?

You can set a package or repository to have a higher priority than another which will play in when smart is resolving dependencies. Which reminds me, does apt even have a way to "lock" a package?

Originally posted by: Nothinman

5) I can keep the same package manager I'm familiar with on most major distros.

The only distros I'm really concerned about are Debian and RHEL..

Good for you..

Originally posted by: Nothinman

6) Apparently there are a few examples where the smart's package management does a "better" job of handling dependencies than apt or yum. Not sure if this is still an issue with apt, but its nice to know smart was developed with dependency issues like these in mind.

I use aptitude most of the time which handles dependencies just fine, it even offers you a list of solutions and lets you pick which one you want to use.

I was just talking about the command-line apt, but yeah I guess if we're talking about gui's then I guess it makes apt a little better. Everything I can do through smart's gui I can do in the command-line just fine.

 

[Nothinman]

Mirrors.

I understand that, but all that extra logic doesn't do a whole lot when a single mirror fills my pipe just fine. Doing 2 downloads from even separate mirrors wouldn't do anything since my bandwidth would be the same and just split between the two, three, etc concurrent downloads.

Its nice to have that built-in to where you don't have to test the bandwidth of each repo/mirror before using it.

See above. Maybe I'm just lucky in that I've almost never seen a Debian mirror be anything close to slow.

You can set a package or repository to have a higher priority than another which will play in when smart is resolving dependencies. Which reminds me, does apt even have a way to "lock" a package?

Base package priorities are set by the maintainer, most things are the same 'optional' priority but since aptitude lets me decide what to do I've never had a problem. And yes, you can put packages on hold, I've got 2 there right now.

I was just talking about the command-line apt, but yeah I guess if we're talking about gui's then I guess it makes apt a little better. Everything I can do through smart's gui I can do in the command-line just fine.

aptitude supports virtually all of the same command-line options as apt, the only one I can think of that's missing is build-dep and that's uncommon for most users. And as I said, the apt-* commands were supposed to be just for debugging assistance but people started using them instead of the recommended user tools.

Does smart track automatic package installs? Aptitude will (and now libapt) will mark any packages brought in as dependencies as "automatically installed" so that it knows it can remove them when nothing else depends on them any more. That alone is worth sticking to apt IMO since it makes for cleaner transitions and when I remove something I know that everything it used is gone too.