Proposal: extension name include package version

[polikuo]

Hi all.
Just sharing some thoughts of mine.

I would probably do something like this:

For shared libraries...
Create a temporary directory, say /tmp/mypackage/usr/local/mylib
Then do something like copying all shared libraries (dependencies included) to that directory.

For executable...
Create 2 temporary directories, say /tmp/mypackage/usr/local/mybin, /tmp/mypackage/usr/local/myscript
Copy all the original bin files into mybin, then create a wrapper script for environmental variables in myscript.

Code: [Select]

#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/mylib
exec /usr/local/mybin/myprogram "$@"Modify PATH in your ~/.ashrc or ~/.profile so you could call your programs more easily

For other entries, you can probably stick to the originals, in case the binaries had path hard-coded during compilation.
/tmp/mypackage/usr/local/share...

Make sure to edit your .desktop shortcut to the wrapper script if available.

Squash up everything (mksquashfs mypackage mypackage.tcz) and try it out in a clean environment.
If you missed something, add that into your package.
Remember to check the environmental variables, some programs need their custom variables set manually.
If no error occur, it should be good.

Kinda like a personal AppImage, more flexible in a way but can be tedious.

[CardealRusso]

After seeing the symmetry of packages in alpinelinux, I had the idea of creating a script to automate tcz, for all tinycore architectures. I would emulate each architecture in qemu, compile and get the files over ssh.

however the "changelog" part in the tcz info would get in the way. this would not be a problem for creating new packages, but packages that are already present, with changelogs from other users, would be problematic. maybe put the changelog for all architectures? for example: "...
2012/06/06 (armv7) etc
2023/06/06 (x64) etc
..." that would be visible in the info of all architectures?
but deep down I wonder if this changelog value really matters. yes, it must have some use, but importance?

[Rich]

Hi CardealRusso

... but deep down I wonder if this changelog value really matters. yes, it must have some use, but importance?

The purpose of the change log is to provide some history
of what changed and when. Changing a package can effect
the behavior of other packages which depend on it. When
that happens, checking the change logs of dependencies
can help isolate which package caused that change.

[CardealRusso]

The purpose of the change log is to provide some history

Hello Rich.

I see a bit of redundancy in having changelog in the .info, since updatelist.txt is supposed to do this job already. If updatelist.txt has a line limit, this could be solved by simply not having a limit.
A new changelog tab could be added in the Appbrowser and it would be very easy to parse updatelist.txt to get the changes for that package. This would also be interesting when showing package changes just for the tinycore version I'm using, as it doesn't seem to make as much sense to me to see tinycore 1.x changelog on 14.x

Another topic. I know very little to nothing about emulating arm. Looks like it needs kernel and device stuff. Could you provide some kernels for armv6, armv7 and aarch64 that I can try to emulate?

[Rich]

Hi CardealRusso

... This would also be interesting when showing package changes just for the tinycore version I'm using, ...

That's nice. Personally, I use the change logs for tracking information, not just
because they might be interesting.

... as it doesn't seem to make as much sense to me to see tinycore 1.x changelog on 14.x ...

Obviously. So next time I need to see the change history of a package, I can find
it by searching through 14 updatelist.txt files. Sounds like fun. And if I need to do
the same for dependencies, the fun just multiplies. 
A packages .info file provides its change history.
An updatelist.txt file provides a Tinycore releases change history.
I always use the .info file because what I'm looking for isn't necessarily from the
current release, or the prior release, or the one before that, ...

... Another topic. I know very little to nothing about emulating arm. Looks like it needs kernel and device stuff. Could you provide some kernels for armv6, armv7 and aarch64 that I can try to emulate?

Maybe one of these is of interest:
http://tinycorelinux.net/13.x/x86/tcz/qemu_arm.tcz.info
http://tinycorelinux.net/13.x/x86_64/tcz/qemu-arm.tcz.info

[CardealRusso]

Obviously. So next time I need to see the change history of a package, I can find
it by searching through 14 updatelist.txt files. Sounds like fun. And if I need to do
the same for dependencies, the fun just multiplies. 

The point of programs and programming is NECESSARY and, from a certain point of view, exclusively to solve this type of problem.

If you can parse one updatelist.txt, you can parse 14 updatelists and get exactly what you want, the complete history. The biggest point is not removing the changelog, as I mentioned earlier, but separating it from the .info, as this will help with future package automation.

Actually I see this solution technically superior, since the changelog tab in separate, there would be less resource usage from both the client and the server (but it would have much more resource usage when clicking on the changelog tab, since it would parse 14 or more updatelists) but since viewing the changelog is not something very common among users, it seems like a good situation.

[CNK]

Even Debian couldn't set separate changelogs right - broken downloads for changelogs in Aptitude are my number one annoyance in Devuan and often with real Debian too. Yes I often look at them - I don't like to upgrade extensions/packages without an idea of what's changed, and it's nice to see how active and established the maintenance of the package is.

I don't understand how it's not possible to automate editing the existing changelogs. It seems to me that it should be easily done in any of many ways, and I can't see how it would be anything like the hardest part of designing the automated cross-compiling system that you describe. Your example before went completely over my head.

Technically it's also possible to use QEMU in a chroot environment ("chroot" is in Busybox and coreutils.tcz, there are also more advanced chroot systems available which would need to be compiled) so that you don't need to boot a separate system and deal with SSH (etc.). You copy the ARM/x86 distro root filesystem somewhere and then switch into that while still running the native system's kernel, and potentially still running its software, or ARM software in QEMU emulation. For building x86 binaries from x86_64 you don't actually need to use QEMU for this because standard x86_64 GCC can build x86 binaries with the right options.

Nothing's foolproof doing it that way though.

[CardealRusso]

I don't understand how it's not possible to automate editing the existing changelogs

Please don't be flippant, this is a text file with no valid formatting. Yes, I know it's possible, but that this lack of standard is bad and makes things difficult

There is no validation, just the senders of the packages supposedly try to copy the same format and if you look at the updatelist.txt now from corepure 64 you will see that the inxi.tcz had the info misspelled
http://tinycorelinux.net/14.x/x86_64/tcz/inxi.tcz.info
and since it was a small error, it was probably not noticed by the sender, nor by the auditee.

Is this really YAML? If so, they should use arrays in the changelog. That would definitely make everything a little easier.

[CNK]

I don't understand how it's not possible to automate editing the existing changelogs

Please don't be flippant, this is a text file with no valid formatting. Yes, I know it's possible, but that this lack of standard is bad and makes things difficult

There is no validation, just the senders of the packages supposedly try to copy the same format and if you look at the updatelist.txt now from corepure 64 you will see that the inxi.tcz had the info misspelled
http://tinycorelinux.net/14.x/x86_64/tcz/inxi.tcz.info
and since it was a small error, it was probably not noticed by the sender, nor by the auditee.

So you're not talking about a practical problem with making your scripts, because with them you can use change-log formatting in the info file that your scripts will understand.

Making the change-log format of other extensions better standardised seems like an entirely separate matter to your automated cross-compiling idea. Personally I don't see a significant benefit.

Is this really YAML? If so, they should use arrays in the changelog. That would definitely make everything a little easier.

I don't think it's YAML. Or if it is then I haven't been doing it very well in the extensions that I've submitted because I've never looked into YAML at all. I think it's more like header fields (eg. in email) really - any line starting with "something:" indicates a new section, and anything else is part of the previous section. Personally I like it.

I don't know whether it's official, but the tcz.info format certainly seems to have been inspired by the Linux Software Map format (also documented here). The change-log is obviously one of the fields that's been added for the TC application. Actually it could be interesting to try adapting one of the old LSM index programs for generating a web front-end to the extension repo. I doubt that the change-log would be much of an issue even with that.