Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: Ulysses_ on April 03, 2011, 09:07:13 AM
-
Several extensions that used to work with older versions of TC do not work currently. Mldonkey is one but there must be more. For anyone not deeply involved in extension development and TC this is a major drawback, because we cannot fix the extensions and we cannot know what version of TC their developer has updated them for.
Nowdays that storage space is cheap, is it perhaps better to have each different version of TC download its extensions from a different version of the repository?
-
There should be no breakage within minor versions, major versions do have separate repos. Please report all such extensions.
-
There should be no breakage within minor versions, major versions do have separate repos. Please report all such extensions.
Alright but is mldonkey's developer around, and does he have the time to update his extension?
Maybe extensions could have an information field that says which version of TC they were tested on last?
-
some packager have created dozens of packages and it is quite normal that they can not keep up with everyone, so the best method is to report directly the malfunction.
however, I tried mldonkey hours, and it works (download as well) (i use latest version of tinycore 3.6.1)
-
I tried mldonkey hours, and it works (download as well) (i use latest version of tinycore 3.6.1)
You mean 3.5.1? What do you type then, to make it work? Do you see the gui?
I get this when typing mldonkey or mlnet:
"Directory /home/tc/.mldonkey is full, MLDonkey shuts down"
-
Sounds like you are running out of memory.
Make sure you configure it do download to real storage.
By the way, current release candidate is 3.6.1.
-
While I'm guilty of taking the same little shortcut at times, it is technically correct to say that the current release candidate is "3.6RC1" where as 3.6.1 will be the first release (if any) between release 3.6 and release3.7. Its quibbling, I know, and its much easier to write it the way it has been used in this thread, but it can lead to confusion.
3.5.1 is the current release. 3.6RC1 is the current release candidate.
-
Thanks, mldonkey sorted. Just needed more memory, works with the current release 3.5.1.
How do you extension developers feel about noting in the description the version of TC the extension was developed for?
-
How do you extension developers feel about noting in the description the version of TC the extension was developed for?
I think it would be rather an exceptional case that an extension from the 3.x repository (i.e. for the TC 3.x series) is targeted specifically for a certain release (e.g. up to TC 3.3) and not for the latest (stable) one (i.e. TC 3.5.1 at the time of this writing).
The reason is that the kernel and the Core libraries (e.g. 'libc') are kept stable (apart from important bug fixes requiring an in-series update) during the life cycle of a given series. What might change between releases of the same series are aspects of the "eco-system" (e.g. support and startup scripts). Therefore I strongly believe that any issues that might arise can be addressed by the extension packagers via small tweaks (e.g. to the extension startup script).
The thing that should not be expected to work outright are using extensions from the "wrong" repository (e.g. a 3.x extension in TC 2.x). And as it requires the user to really work (deliberately) against the TC "eco-system" to create such a situation I'd see such information in the extension info files as rather unnecessary.
-
Agreeing, and the "Change-log:" and "Current:" after all are present in the .info.
And comparing, there is quite a number of extensions which has the same "Current::" date in repo of 2.x and 3.x
-
And comparing, there is quite a number of extensions which has the same "Current::" date in repo of 2.x and 3.x
All the extensions that it was thought would not be affected by the update 2.x -> 3.x were copied across to the new repo - there have not been many reports of problems..
-
A related issue is some extensions used to be available but not any more. Eg open-vm-tools. This extension is mentioned in the forum, but where do I download it from? And once downloaded, how do I find out what TC it goes with?
If we look at the "Change-log:" and "Current:" fields in order to compare them with TC dates, I only see TC 3.x dates under Downloads. Where are 2.x ones?
And shouldn't all extensions it depends on be available too, at the corresponding version each?
-
Surely all such version comparisons are for a computer to make, not a human?
-
A related issue is some extensions used to be available but not any more. Eg open-vm-tools. This extension is mentioned in the forum, but where do I download it from?
I'm working on it today. :)
-
Cool.
So a TC repo is always about 1% broken and that is by design?
-
And comparing, there is quite a number of extensions which has the same "Current::" date in repo of 2.x and 3.x
I build almost all of my extensions in 2.11.6 and submit them to the 2.x and 3.x repositories.
-
Cool.
So a TC repo is always about 1% broken and that is by design?
You have mentioned one extension (mldonkey), which wasn't broken :P
On open-vm-tools, there never has been a 3.x extension for that so far, as far as I know.
-
In any case, how would I bring open-vm-tools back from the grave if danielbarnes were on holiday? Do you see my point?
-
In any case, how would I bring open-vm-tools back from the grave if danielbarnes were on holiday? Do you see my point?
Repo is user contributed. You have three options:
- wait for someone is building the extension you need
- you are doing it yourself
- forget it
That's the point. Relax.
-
If we look at the "Change-log:" and "Current:" fields in order to compare them with TC dates, I only see TC 3.x dates under Downloads. Where are 2.x ones?
They get more and more rare by the process of periodical version bumps. Would you have checked within a short time after 3.0 was released, you could have noted a totally different analogy.