Expanding LibreTime: Need help with packages.py

Get Help
1

Hi All,

I’m apparently enough of a newbie the system won’t let me post any more links, but if you look under my profile you’ll find I posted an entry titled: " Moving beyond four linux versions: Could use some help".

I tried posting my new install script and it says I can’t post any more URLs yet - it points to my own web site where you can find a new Fedora-friendly install script! IT WORKS! And, it also supports the previous four versions, etc - see that other posting’s replies for more (once it finally posts, perhaps).

And, now I’m at the point where I need some Python help:

╔══════════════════════════════════════════════════════════════════════════════╗
║ Shared ║
╚══════════════════════════════════════════════════════════════════════════════╝
usage: packages.py [-h] [-f {list,line}] [-d] [-e EXCLUDE]
{buster,bullseye,bookworm,bionic,focal,jammy} path
[path …]
packages.py: error: argument distribution: invalid choice: ‘Thirty Five’ (choose from ‘buster’, ‘bullseye’, ‘bookworm’, ‘bionic’, ‘focal’, ‘jammy’)
at:

I’ve only ever edited a few Python programs and never written one. However, this script MUST be edited.

It needs to accommodate more versions, and that’s my goal.

SURE, I can add to that list without further help, BUT… That’s a “half-assed” solution.

How about it just drop the pretense of being perfect and just letting it all through? I might be able to edit it to do that, but this is “beyond what I signed up to do.”

Someone? Please?

We need a design that doesn’t inhibit expansion to more releases!

Thanks!

2

I can only recommend you to read the script, there is nothing magic in there.

The script takes a distribution codename and a path to a packages.ini, opens the packages.ini file, and filter/list all the packages that are required by the distribution codename.

$ tools/packages.py --help
usage: packages.py [-h] [-f {list,line}] [-d] [-e EXCLUDE] {focal,bullseye,jammy,bookworm} path [path ...]

positional arguments:
  {focal,bullseye,jammy,bookworm}
                        list packages for the given distribution.
  path                  list packages from given files or directories.

optional arguments:
  -h, --help            show this help message and exit
  -f {list,line}, --format {list,line}
                        print packages list in a specific format.
  -d, --dev             include development packages.
  -e EXCLUDE, --exclude EXCLUDE
                        exclude packages sections.

To add your distro, you need to add en entry in libretime/packages.py at main · libretime/libretime · GitHub and complete the many packages.ini files in the repo libretime/packages.ini at main · libretime/libretime · GitHub.

3

Hi joola,

Here I ask, do I understand you correctly?

For clarity, I think you’re asking that:

I should use my (long existing) git-hub account and do a pull request and then put my changes there and then ask for them to be accepted?

Patches are, well… nothing I want to do. But read on, please.

Note that for what I have done already, “just for me” goes WAY beyond just what I need to do. And what I want to do for the community bears extraordinarily little relationship to contributions in Python or Postgres as contemplated in the materials you pointed me to - I read all of them.

My work already is in support of C4 section 1 points 1 and 4, which state:

  1. To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;

The scale and diversity are improved by having more diverse distributions and versions.

  1. To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;

When it comes to the installation, the problem is that the original installation script has no such provisions, presuming that “the natural life cycle” is interested in expanding the project beyond two versions of two distributions of Linux. And even if it was just limited to debian and ubuntu, the existing installation script is not really contemplating the future in a mature way.

A likely reason is that coders nearly universally ignore installation issues, as a recent dialogue I had with one Bil Auger on the Media Goblin developer’s list illustrated. … I’m not trying to be argumentative, I’m just trying to say that as a senior guy in our industry I know about this stuff intimately and have already got something that the current folks can likely run with and be more successful with. (My latest version is a substantial improvement over what I posted already - which was preliminary - and I need to do a bit more to complete the job.)

It’s worth pointing out that these changes are such a major reorganization and change to the installation script that it is simply ridiculous - ahem - inefficient to an extreme - to ask for several hundred patches (as outlined in the documents you pointed me at) when a simple replacement of the file (it’s just one file), tested by others on all platforms to ensure it works, is a vastly more efficient way to go. And that, by the way, is goal C4 section 1 point 3 - I can quote if you want!

Further, my work - that I’ve already done - restructures the former work so that it will be easy to add not just new releases but new platforms, especially those that use Redhat Package Manager - and that’s a LOT of systems.

Further, there’s a VERY good argument to be made - that I’m not really making here - that the use of release names is a big mistake, and that code should be changed to just use it to make humans happy in display but not use it in making decisions about what the code should do because it’s not fine-enough grained. But that’s not really my concern - I don’t have time for that. But the folks who wrote it in the past should reconsider, in my view.

It’s a LOT more work for me to do what I believe you proposed than if I’m just given the audience to talk with and can share what I’ve done and leave it to them.

But, it’s really up to you folks.

4

Hi,
Sorry but I don’t understand what you want. By reading you, I feel like you are arguing or making a point about something, I don’t know what though.

  • Feel free to criticize the work that has already been done, every person discovering a new project does that.
  • Feel free to fix what you consider broken, rewrite a script, or rebuild the project.
  • Feel free to contribute back to Github, if you don’t want, you can always publish your work here, some might want to use it. But if you want your work in LibreTime, you will have to go through the Fork/PR/Review/Merge workflow.
  • Feel free to ask for help but please be concise and specific in your questions.

If you don’t have time, well, don’t do it. Nobody is forcing you.

Jo

5

So the reason LibreTime utilizes release names to determine this is because it is dependent on a lot of specific packages and is somewhat coupled with the Debian package system which has different versions for different releases. This decision was made a long time ago before LibreTime existed and it was still Airtime. Perhaps Fedora does things differently and in that ecosystem it makes no sense to tie things to specific packages.

The bigger challenge with officially supporting a new system is the time it would take to support it and help people troubleshoot problems, not to mention the changes to the current install scripts.
If you want to make LibreTime a part of your life feel free to make pull requests and figure out how to officially contribute otherwise you can participate on here.

1 Like