Documentation suggestion

[ghost]

This is easily the most flexible command-line podgetter out there, however, a little tweaking will greatly improve the docs and experience for people.

Firstly, I struggled because I didn't realise that when you do apt install podget on Ubuntu you end up with 0.7.9, and everything goes wrong!

Adding simple build instructions would help greatly:

wget https://github.com/dvehrs/podget/archive/dev.zip
unzip dev.zip
cd dev
make && make install

Next, hardly any github repos use Wiki, so I'd not even thought of looking at https://github.com/dvehrs/podget/wiki - could do with a link from the main page.

Would you like me to make a couple of changes and submit a pull request for these?

Finally, Googling for podget turns up a very old and outdated site at http://podget.sourceforge.net/ - if you still have access to that page, it might be an idea to redirect people to Github!

[dvehrs]

Starting with flattery will get you everything!

For the first issue. That is a common problem. I upload the new versions of Podget into Debian Sid and they are soon incorporated into Debian Testing (Buster right now). If you're running an older version of Debian (Stretch or older) then the version of Podget you get is dependent upon what was the last version accepted while it was still the Testing branch. This problem carries over to all of the other distributions (like Ubuntu) that fork off Debian. The version in their repositories depends on when they forked off and what version they based on.

However as you have discovered, there is little in the current version of Podget (or even the DEV branch) that prevents someone from using it on an older release of Debian or Ubuntu.

As for the Sourceforge page. Yes the website it has for Podget is dated but that's were it was first shared. However I keep the downloads section up to date with new releases on the same day I post them to Github. So the only part that Sourceforge does not see are the development branches (DEV, etc.). I should probably add something onto the default webpage that points at Github, but I honestly have not maintained that webpage for ages. Ooops.

Third as for a pull request, I hope that i will never tell anyone not to. I can't promise that I will accept all pull requests but I believe I have a fairly good record of accepting those that fit and for those that don't working with the submitter until we reach a solution that is acceptable to us both. So I place the ball in your court, if you feel a pull request is the most effective way to share the changes you'd like to see then by all means submit one. Or if you think it would be more effective to discuss them here then do it and we can integrate the changes.

The only suggestion I would throw out to start it is that we include a reasonable warning before we point people at the DEV branch. It's mostly stable but there are times when it is less so depending on what features I may be working on.

So balls in your court, how would you like to proceed?

Dave

[ghost]

Thanks Dave! OK, give me a couple of days and I'll put together a short pull request. Thanks!