OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: André Heldoorn on May 07, 2019, 04:03:29 pm

Title: Discussion about RPM/YUM and Libcn
Post by: André Heldoorn on May 07, 2019, 04:03:29 pm
I noticed today that "libcn0.dll" is available on the regular (non experimental) netlabs rpm repository. That means that regular users can now get that DLL.
Thank you. Albeit I dare to state that "regular" implies all brands of OS/2, and mainly installs without bleedin' RPM, so it's a bit of a stretch to imply that ArcaOS and perhaps eCS 2.x are representing what "regular" is.

I haven't seen a more regular *CN* RPM ZIP file so far, FWIW. ArcaOS will be regular for users of an English OS indeed, but that's a minority. Surely you aren't claiming that users of e.g. a Spanish version of OS/2 aren't "regular users"... :)
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 07, 2019, 04:21:40 pm
I noticed today that "libcn0.dll" is available on the regular (non experimental) netlabs rpm repository. That means that regular users can now get that DLL.
Thank you. Albeit I dare to state that "regular" implies all brands of OS/2, and mainly installs without bleedin' RPM, so it's a bit of a stretch to imply that ArcaOS and perhaps eCS 2.x are representing what "regular" is.

I haven't seen a more regular *CN* RPM ZIP file so far, FWIW. ArcaOS will be regular for users of an English OS indeed, but that's a minority. Surely you aren't claiming that users of e.g. a Spanish version of OS/2 aren't "regular users"... :)
He never implied regular OS/2. He was speaking of the regular RPM repository.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Doug Bissett on May 07, 2019, 04:28:31 pm
Quote
Thank you. Albeit I dare to state that "regular" implies all brands of OS/2, and mainly installs without bleedin' RPM, so it's a bit of a stretch to imply that ArcaOS and perhaps eCS 2.x are representing what "regular" is.

Sorry, but modern OS/2 includes RPM/YUM support. To say otherwise is equivalent to saying that Warp 4 was not "regular" OS/2, because it added network support, that Warp 3 did not have. "Regular" OS/2 is what is available TODAY. Even eCS is obsolete. You can add some things, like RPM/YUM support, to older versions of OS/2, but they are still obsolete.

Quote
ArcaOS will be regular for users of an English OS indeed, but that's a minority.

Language support is coming for ArcaOS. Translations are happening, but it takes a LOT of hard work (and time) to find all of the parts, change them, verify that the changes were correct, and test the changes. Then they need to adjust the rest of the OS to handle different languages properly. Many changes are already incorporated, but language support is not ready, yet.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Sigurd Fastenrath on May 07, 2019, 11:13:56 pm

Sorry, but modern OS/2 includes RPM/YUM support. To say otherwise is equivalent to saying that Warp 4 was not "regular" OS/2, because it added network support, that Warp 3 did not have. "Regular" OS/2 is what is available TODAY. Even eCS is obsolete. You can add some things, like RPM/YUM support, to older versions of OS/2, but they are still obsolete.

Sorry, this seems to be wrong as well, at least I remember a version that was called OS/2 Warp connect, based on Warp 3 with allmost all the network parts that have been recycled in Warp 4.

Language support is coming for ArcaOS. Translations are happening, but it takes a LOT of hard work (and time) to find all of the parts, change them, verify that the changes were correct, and test the changes. Then they need to adjust the rest of the OS to handle different languages properly. Many changes are already incorporated, but language support is not ready, yet.

If you believe it or not, repeating things and the same arguments like you are doing for years know (just like your comments on USB 3, WLAN and so on) does not change anything or make things happen. I am reading this for ages now, every time the same answers if someone is going to critizise your "holy" ArcaOS. It might be worth to consider, that some users did trust in the promises that "there will be sometime this and that feature" and paid a reasonable amount of money - but these things are still not there, as there is allways "something else more important". So it is up to everyone himself to judge about ARcaOS in a way he/she does, it does not depend on the opinion of someone else.

And if you believe it or not, it is still possible to add allmost all enhancements from ArcaOS to a Warp 4.52, without using YUM/RPM, I did this last time in December last year when I decided to stop for a while with ArcaOS, nativ on a Thinkpad 25.

I just reactivated, renovated, repaired my Pentium III 600 Mhz PC from 1999, and OS/2 Warp 4.52 is running fluent on it. It just works as it ought to. For now I am collecting hardware to reassemble my first PC from 1995 with original parts - and the riginal preinstalled software. That makes so much fun!

Cheers and all the best! ;)

EDIT: if interested in, you can follow my Retro PCs at the OS2.DE Forum, here: https://www.os2.org/viewtopic.php?f=19&t=1652 (https://www.os2.org/viewtopic.php?f=19&t=1652)
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Alex Taylor on May 08, 2019, 01:53:21 am
Quote
Language support is coming for ArcaOS. Translations are happening, but it takes a LOT of hard work (and time) to find all of the parts, change them, verify that the changes were correct, and test the changes. Then they need to adjust the rest of the OS to handle different languages properly. Many changes are already incorporated, but language support is not ready, yet.

This is not quite accurate.  The necessary hooks for language support are already largely implemented in ArcaOS.  The number 1 bottleneck is finding people to actually do the translations.  (That said, Spanish and German are well on their way to readiness.) 

However, non-English versions of ArcaOS are, as they always have been, planned for version 5.1, not 5.0.  This has not changed since the earliest announcement of ArcaOS as a product.

If you believe it or not, repeating things and the same arguments like you are doing for years know (just like your comments on USB 3, WLAN and so on) does not change anything or make things happen. I am reading this for ages now, every time the same answers if someone is going to critizise your "holy" ArcaOS. It might be worth to consider, that some users did trust in the promises that "there will be sometime this and that feature" and paid a reasonable amount of money - but these things are still not there, as there is allways "something else more important". So it is up to everyone himself to judge about ARcaOS in a way he/she does, it does not depend on the opinion of someone else.

I really have no idea what you mean by this.  TTBOMK, there is no feature that was promised for ArcaOS 5.0 has not been delivered.  (You mention USB3 and WLAN, which are part of the driver subscription roadmap, not ArcaOS; while they may have been mentioned as aspirational items for 5.1 – which is not out yet – they have never been advertised as ArcaOS 5.0 features.)


(Note: I am not speaking officially on behalf of Arca Noae; nor, for that matter, is anyone else who has posted in this thread so far.)
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Doug Bissett on May 08, 2019, 02:14:45 am
Quote
Sorry, this seems to be wrong as well, at least I remember a version that was called OS/2 Warp connect, based on Warp 3 with allmost all the network parts that have been recycled in Warp 4.

And that was subsequently replaced by SAMBA (which still has some serious problems, but works better than Lan Manager, in modern networks).

Quote
If you believe it or not, repeating things and the same arguments like you are doing for years know (just like your comments on USB 3, WLAN and so on) does not change anything or make things happen.

You have no faith. I do have a test version of the USB 3 driver. it loads, but still doesn't connect USB devices. Small steps forward, but it is just a more difficult project than anyone expected.

Saying that it isn't happening is not helpful. If Arca Noae had another 200 competent programmers, a lot of that stuff could have been done long ago. As it is, the very few who are doing the job are overworked, and they can't spend every hour of the day working on those projects. It all takes time, and every one has more than one job to do.

Quote
And if you believe it or not, it is still possible to add allmost all enhancements from ArcaOS to a Warp 4.52, without using YUM/RPM

If you actually believe that, you have no idea what you are saying. There are many things that are in ArcaOS, that cannot be made available for older versions of OS/2. The contract with IBM forbids it. Arca Noae has permission, from IBM, to distribute patched versions of the IBM software (the kernel, for example), but only for those who use ArcaOS. Nobody else has permission to do that, or to use the Arca Noae patched software. Others may do it, illegally, without drawing any interest from IBM, but Arca Noae must stick to the rules of the contract.

RPM/YUM contains far more than just DLLs (and is outside of the IBM contract). Have you installed all of that too? RPM/YUM can be installed on older versions of OS/2 (I suggest using the free Arca Noae Package Manager, to make it much easier), and takes a big step toward getting OS/2 updated to run modern software. Doing that manually is a waste of time, and effort, because you are unlikely to get all of it installed correctly. Use the proper tools for the job, and you get a better end result, with a lot less work. Having said that, I will admit that I do not like RPM/YUM, but it is the tool that is provided, and it works until a user tries to outsmart it, or until somebody provides  a bad package (which hasn't happened to me, recently).
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Sigurd Fastenrath on May 08, 2019, 08:34:04 am
First of all - sorry to Jochen, for using his thread in this way! Dosbox is really great and I really do appreciate your work!!!

Just for once again, and just to proof that Doug is wrong I will answer to his reply:

You have no faith. I do have a test version of the USB 3 driver. it loads, but still doesn't connect USB devices. Small steps forward, but it is just a more difficult project than anyone expected. Saying that it isn't happening is not helpful. If Arca Noae had another 200 competent programmers, a lot of that stuff could have been done long ago. As it is, the very few who are doing the job are overworked, and they can't spend every hour of the day working on those projects. It all takes time, and every one has more than one job to do.

As I wrote before and as it is usual: repeating the same things again and again....

And for the "wishes, Projections and so on": take a look at Lewis Presentation at Warpstock Europe 2017, where there are mentioned:

- USB 3.0 in the works (2016 David said it is about 95% done)
- Mulitmac Wifi is in the works (?)
- Language Pac conversion from english for installed en_US 5.0 systems (not 5.1!)
- not to mention: UNIAUD

This stands there side by side with things like "Migration" and so on.

Yes, everything is to AN to decide what is important to them or not (as I wrote multiple times before) and everything is a wish list and so on. But when it comes to the end, down to facts, the three things most important to me are allways falling down to the end of the list. It is not complaining, it is just the way it is.
And it does not help to repeat againg and again the well known facts with the lack of developers and so on and so on. And yes, AN has to serve industrial customers first, to make profit. But if your focus is more and more to "Just" make profit, you do not have to wonder if the "usual" user turns to something else. As easy as this.

If you actually believe that, you have no idea what you are saying.


Here again the usual answer, when you are running out of facts or arguments.

And even worse: you might consider that such replies may harm users, do show no respect, and finally even worse - discredit them.


There are many things that are in ArcaOS, that cannot be made available for older versions of OS/2. The contract with IBM forbids it. Arca Noae has permission, from IBM, to distribute patched versions of the IBM software (the kernel, for example), but only for those who use ArcaOS. Nobody else has permission to do that, or to use the Arca Noae patched software. Others may do it, illegally, without drawing any interest from IBM, but Arca Noae must stick to the rules of the contract.

Wrong again:
 
The one and only thing that one might need and is "illegal" (in fact there is no need for) is the new Kernel 14.201 (14.200). Everything else can be replaced by using the Software Subscription or free available parts. And in addition my Warp 4.52 clone is not 1 by 1 ArcaOS as there are a lot of things I do not need.

i.e.: (everything what I am writing here is proofed and working!)

- For the loader I use the full QSINIT, wich gives the opportunity to load different config.sys and different kernels
- with older version of ACPI you can still use Kernel 14.106SMP
- even the newest ACPI works with that kernel, even if it then reduces the kernel to "One"
- even one can use this version with the latest OS/4 kernel and ACPI4 file, if one wants to have SMP, there is no need for the AN ACPI then
- for USB there are Lars Drivers, and so on and so on.
- AHCI, Network, Panorama ... are all included in the software subscription
- and, by the way, did you get your hands ever on Kernel 14.113b? Or did you ever heard of it?


RPM/YUM contains far more than just DLLs (and is outside of the IBM contract). Have you installed all of that too? RPM/YUM can be installed on older versions of OS/2 (I suggest using the free Arca Noae Package Manager, to make it much easier), and takes a big step toward getting OS/2 updated to run modern software. Doing that manually is a waste of time, and effort, because you are unlikely to get all of it installed correctly. Use the proper tools for the job, and you get a better end result, with a lot less work. Having said that, I will admit that I do not like RPM/YUM, but it is the tool that is provided, and it works until a user tries to outsmart it, or until somebody provides  a bad package (which hasn't happened to me, recently).

First of all, I do have no intention to persuade someone to do it the way I do it, it is just that this way is possible.

We have a good saying here in German (in fact it might be just translated from another language though):

Alle sagten: es geht nicht! Dann kam einer, der das nicht wusste und hat es gemacht.

And the fact, that YOU never tried it or never succeeded does not necessarily lead to the conclusion that it is not possible or does not make sence!

And no: I do not use ANPM with this clone anymore, I did it sometime before, but did not like the unix structure. Even if it is a simpler way to use these dlls.

If the result is better or not does depend on each users opinion as well. Your opinion is not a kind of "ordeal", and so is mine. For me the result is still better than what I get with ArcaOS (so far) as it is i.e. in German, I do not have a "Unix like tree", and everything works as expected, with the same problems with some hardware or applications I do have had with ArcaOS as well.

By the way: It takes me usually a maximum of two days, each 6 hours, to build an up to date OS/2 while starting from scratch (OS/2 4.52, aka MCP2), inlcuding the ability to install Samba, Samba Server, Warp Server and and and and....

Again, all the best to all of you!

Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 08, 2019, 10:23:05 am
Hey guys.

Calm down. There is a reason, why I include all the necessary DLLs in the DOSBOX package.
That I once build a binary with a still experimental DLL was a slip.
Martin is helpfully pointing me to the new status of LIBCN.
What is not helpful is the bickering about the one true OS/2. You don't need RPM for DOSBOX.
BTW, if you get the newest LIBC from a non-RPM source and build against it, guess what, you are still needing LIBCN.

So, please stop it guys.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: André Heldoorn on May 08, 2019, 02:14:31 pm
He was speaking of the regular RPM repository.
I'm afraid you are overlooking the far more important "regular users". People.

In general not demoting such an innocent type of friendly, daily conversations is an efficient way to reduce the size of a whole community quickly. The happy few branding themselves as representatives of regular users. No Open Object Rexx for OS/2 is an example, or the reduced number of Italian users since IIRC an Italian eCS 1.2 and of course the underlying problem isn't his - if anything - open point of view. The reduced number of available OS languages is.

In a nutshell I'd recommend to not exclude OS/2 and relevant OS/2 hardware. A Korean Warp 4 with an informal, own FixPack, for example. With eCS 2.x DE the German speaking community still belongs to the happy few too. Good for you, brilliant, but please keep in mind that easily ignoring "regular users" is a great way to reduce the size of a community. It's quite normal to state that they aren't "regular users", as can be seen above. Actually those "regular users" will be the most up-to-date minority. Anything but regular.

AFAICT the appreciated DOSBox/2 works fine for the whole family of brands, without requiring tools of the happy few.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 08, 2019, 03:13:22 pm
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Dave Yeo on May 08, 2019, 04:36:10 pm
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?

The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Martin Iturbide on May 08, 2019, 06:13:50 pm
FYI: I split this topic.

PD: Today I'm drinking a "regular" size coke.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Martin Iturbide on May 08, 2019, 07:56:33 pm
Hi

Maybe my mistake was to write "regular users" referring to the people that does not use the "Netlabs experimental RPM Repository", and use just the normal "netlabs RPM repository". For the record, I did not mean to say it as a pejorative or derogatory term, I usually don't use the experimental RPM repository on my OS/2-ArcaOS systems.

Regards
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Roderick Klein on May 08, 2019, 10:48:31 pm
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?

The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality.

David his comment makes perfect sense.

If you would write a program on OS/2/ArcaOS that would not depend on the family of LIBC/GCC DLL's in the \USR\LIB. So it would use DOSCALL1.DLL or PMMERGE.DLL, would you include a version of that DLL in your ZIP with your application ?

I certainly would not hope so.  From my perspective it makes very little technicall sense.  Infact including a version of for example PMMERGE.DLL is potentially playing Russian roulette.  The fact files such as LIBCXX they do not come with the natve list of files IBM provides with the OS is not really an important point. By now the vast mayority of the software we port from Linux leans on these DLL's. It is in effect an set of new system DLL's badly needed to run pretty critical applications such as your browser and or mail client.

While I am certainly not a very big fan of YUM/RPM. As Silvan from BWW mentioned. They where loosing waay to much time on support because people could not get the proper DLL version installed. This is why they switched to an RPM only format. BWW just like most other developing software for OS/2 are short on time.

While its a free world it would be easier for deveopers to embrace the YUM/RPM system to update system DLL's.
Also people using your application could run into issue's with outdated DLL's.

Having been to local OS/2 usergroup meeting in Netherlands. Three people ran ANPM to update the DLL's.
That was a whole easier then fiddeling around with ZIP files.

Roderick

Title: Re: Discussion about RPM/YUM and Libcn
Post by: ivan on May 08, 2019, 10:51:09 pm
Hi Dave,
Quote
The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality

The converse is also possible with the newer version breaking older programs - yes I know that those producing the new version can't test it against every program that uses it.  That is why I have always tried to put everything a program needs to run in the directory of the program  and run everything from there.

One possible workround would be to go the whole hog and use a program that makes a snapshot of the OS just as they do in Linux Mint, then if anything goes wrong everything can be restored to the previous working state.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 08, 2019, 11:14:18 pm
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?

The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality.
Yes, but the DLLs are installed in DOSBOX's directory. DLL hell, I know, but at least nothing gets mixed up.

Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 09, 2019, 01:46:16 am
The converse is also possible with the newer version breaking older programs - yes I know that those producing the new version can't test it against every program that uses it.  That is why I have always tried to put everything a program needs to run in the directory of the program  and run everything from there.
That would increase the limitation caused by short shared memory extremely. It isn't a good idea, IMO.

A package writer can handle the problem better then simply adding DLLs that may be already installed by other packages: He can make the installation (addition) of these files optional and add code to preselect the proper selection state for it. For most users, the preselection is important, IMO. That's convenient for non-RPM users.

For an RPM user, it's important that a check for missing dependent packages is made before the preselection. Otherwise he may unintentionally end with a system having both local and common system DLLs, if system DLLs are included. In case anything misses, it should either be installed optionally or at least a message should pop up how the dependent packages have to be added (a yum or ANPM line).

IMO, it's better to assume the RPM method is used for installing system files. Additional dependent system DLLs should better be distributed in another package, if at all, for non-RPM users.

Both methods are possible with WarpIN, but one needs quite some code. Additionally, the next ANPM versions could handle the case when system DLLs were already installed by WarpIN packages. Much depends on how thoroughly the package writer has worked.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Doug Bissett on May 09, 2019, 02:19:23 am
Quote
It isn't a good idea, IMO.

It is definitely a very BAD idea, IMO. If a package is to include DLLs, they should have unique names, and never duplicate what is in RPM/YUM.

Quote
That's convenient for non-RPM users.

I don't know about others who package programs, but after spending a lot of hours trying to figure out how to do that with Firefox (a few years ago), I came to the conclusion that I have better things to do with my life. If a user insists on doing that manually, they can do the work to figure it out. I can usually install all listed packages in a couple of minutes, using ANPM (Arca Noae package manager), and it gets done right. At the time, there were a few people who spent days trying to get things right, for Firefox. Most packagers just don't have the time to do that, and I hate to see programmers wasting their time doing it. It should be sufficient for them to list the required packages, and let ANPM (RPM/YUM) figure it out for the users.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Dave Yeo on May 09, 2019, 02:58:45 am
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?

The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality.
Yes, but the DLLs are installed in DOSBOX's directory. DLL hell, I know, but at least nothing gets mixed up.

And, for example, they start Dosbox first, which loads the old libc and then starts something else that needs a newer one and the other program won't run, the user will be left scratching their head, not understanding that Dosbox loaded the wrong libc into memory and other programs are using that version.
Libc is as much a system dll as anything and just like other system dlls such as PMMERGE, shouldn't be included in your program.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Dave Yeo on May 09, 2019, 03:07:33 am
Hi Dave,
Quote
The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality

The converse is also possible with the newer version breaking older programs - yes I know that those producing the new version can't test it against every program that uses it.  That is why I have always tried to put everything a program needs to run in the directory of the program  and run everything from there.

One possible workround would be to go the whole hog and use a program that makes a snapshot of the OS just as they do in Linux Mint, then if anything goes wrong everything can be restored to the previous working state.

Libc is one library where backwards compatibility should always be expected, and gets tested when in the experimental repository. If backwards compatibility is broken, the version will be changed.
It is easy to take a snapshot like Mint does if you choose, it just uses rsync.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Dave Yeo on May 09, 2019, 05:23:16 am
Another option if you insist on adding libc etc is to enforce BEGINLIBPATH and LIBPATHSTRICT so the ones that come with DOSBOX are used only by DOSBOX. Something like
Code: [Select]
/* Add directory where EXE is located to LIBPATH */
/* And set LIBPATHSTRICT */
DosSetExtLIBPATH((PCSZ) basepath, BEGIN_LIBPATH);
DosSetExtLIBPATH((PCSZ)"T", LIBPATHSTRICT);
basepath could even be .\.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 09, 2019, 11:19:06 am
1.) The DLLs are their own package and don't need to be installed. @Andreas, how can I switch the default state of a package. Honestly, 15 years ago, when starting porting and maintaining DOSBOX, somebody write me the Warpin scripts.

2.) @Dave: Good hint. I will try to insert that in the next release.

EDIT:
3.) I really would to also build an RPM version, but I can't even get the SDL extension to build, because dynamic build seems to be impossible.

I'm open to suggestion about how to make the package better and more reliable. I'm just not familiar with every OS/2 intricacy, as I'm only use it to build DOSBOX.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Dave Yeo on May 09, 2019, 04:35:34 pm
EDIT:
3.) I really would to also build an RPM version, but I can't even get the SDL extension to build, because dynamic build seems to be impossible.

I'm open to suggestion about how to make the package better and more reliable. I'm just not familiar with every OS/2 intricacy, as I'm only use it to build DOSBOX.

How are you building Dosbox, GCC or OpenWatcom? And likewise with the SDL libraries?
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 09, 2019, 10:41:34 pm
@Andreas, how can I switch the default state of a package.
It's no problem to give examples. (NEPMD, my project, is one.) But from what you wrote after that, it seems that you rather need other support for that.

Honestly, 15 years ago, when starting porting and maintaining DOSBOX, somebody write me the Warpin scripts.
I don't remember how Dosbox is distributed. My first thought today: If I'll find time I'll enhance the WarpIN installation. Bur after having read what I wrote last night and what others wrote about system DLLs, my opinion has changed a bit:

In NEPMD, I've included 1) md5.exe by Bob Eager, 2) lxlite.exe and unlock.exe and 3) wptools.dll. These are must-have tools to allow NEPMD process basic functions.

To 1) md5sum is nowadays installed on modern systems. md5.exe is then deactivated on installation. But unfortunately an already installed md5.exe NEPMD tool is not automatically uninstalled if md5sum.exe was found in the meantime. Md5.exe itself hasn't changed in the past and because it's an EXE and not a DLL, it won't interfere with other apps. Therefore: No problem to provide md5.exe with NEPMD. I've left it in the NEPMD package, because it was included already before the RPM/YUM times. The same applies to both other tools.

To 2) lxlite.exe and unlock.exe are system tools since an eCS version. They haven't changed much in the past. bww has released a new version with included changes from various people. I had replaced the previous Hobbes files with the bww files in the NEPMD package. Again, these files are EXEs, so it's no problem for other apps. There were installed in a tools dir that is not included in NEPMD's extended PATH. That means that also from command line, ther's no danger with these files.

To 3) wptools.dll is included since an eCS version. Even being a DLL, distributing it maybe additionally with a package may cause no problems, because development has stopped and it hasn't changed since ages.

But I won't include any of the e.g. gcc* DLLs with NEPMD, because such files are maintained and changed often.

So in your case, I find it the best method to avoid inclusion of these files. That applies also to libcn. If you want to support people who defer to use RPM/YUM, I see it as the only option to provide the required files in a separate package. (Steve Wendt did that for Mozilla versions.) With "package" I mean also "file". That means: create a special .wpi with these DLLs, but better keep them quite hidden to ensure people don't install them by mistake.

Dave has already described what the biggest problem for other apps may be. So, easiest is to just refer to the "yum install" command to install the prerequisites. What WarpIN can do, is to check for prerequisites and defer installation without it. Let's see, if I find time during the weekend to give examples and to add that to the Dosbox .wis script.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 09, 2019, 11:24:11 pm
How are you building Dosbox, GCC or OpenWatcom? And likewise with the SDL libraries?
GCC 4, SDL from RPM.
I have to built the SDL dependencies like Ogg, SDL_net statically. I'm not able to build DLLs from them.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 09, 2019, 11:31:33 pm
I find it the best method to avoid inclusion of these files. That applies also to libcn. If you want to support people who defer to use RPM/YUM, I see it as the only option to provide the required files in a separate package. (Steve Wendt did that for Mozilla versions.) With "package" I mean also "file". That means: create a special .wpi with these DLLs, but better keep them quite hidden to ensure people don't install them by mistake.

Dave has already described what the biggest problem for other apps may be. So, easiest is to just refer to the "yum install" command to install the prerequisites. What WarpIN can do, is to check for prerequisites and defer installation without it. Let's see, if I find time during the weekend to give examples and to add that to the Dosbox .wis script.
Very helpful remarks. Since 15 years, I on and off release some Warpin packages for DOSBOX. Nobody ever complained about how I package it or suggested how to do it better.
Thank you Andreas and Dave.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Dave Yeo on May 10, 2019, 02:41:40 am
How are you building Dosbox, GCC or OpenWatcom? And likewise with the SDL libraries?
GCC 4, SDL from RPM.
I have to built the SDL dependencies like Ogg, SDL_net statically. I'm not able to build DLLs from them.

Why not use the RPM version of libogg? SDL_net.dll (or sdlnet.dll) should be easy to build, though by going static, you do avoid DLL hell.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 10, 2019, 08:31:32 am
I don't know anymore. Perhaps it was the DOSBOX configure script acting up.
In the end, it comes down to me wanting to produce the RPM packages for the dependencies, but not being able to.
I wanted to look into the SDL source package, anyway. Perhaps there I can unearth something.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Martin Iturbide on May 10, 2019, 01:57:21 pm
Hi

I have some issues with the SDL 1.2x on the rpm package with some SDL ported games I'm trying.
1) There is the confusion between sdl and SDL on the repository.
2) It seems that some DLLs are missing like the mixer, image, net, sound on the rpm package. Checking the contents of the SDL and sdl packages does not list those.

This is why I had skipped the SDL (and sdl) package from the rpm repo and started using the ones on hobbes (SDL-1.2.15-20160303.zip and SDL2-2.0.4-20160225.zip) for trying the game SDL apps.

As a convenience I would like to have a full SDL1 and SDL2 DLL's on the rpm repository and I will like to have DOSBox/2 also installable from rpm. Like I said before on this forum, I dislike FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) and using rpm/yum from command line, but since we have ANPM (https://www.arcanoae.com/resources/downloadables/arca-noae-package-manager/), I was able to tolerate it.  But it is just my personal opinion.

Regards
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Doug Clark on May 11, 2019, 07:38:11 am
My 2 cents for what it is worth:

1) I think Arca Noae is doing a great job. They may not have delivered everything that was promised, but I am amazed at what they WERE able to accomplish; things that I thought would never happen. Such as getting SNAP to work with multiprocessor systems. The fact that Arca packages stuff together (even if it is stuff that is available separately,) and tests it, is worth alot to me. Easily worth the money they charge. Just my opinion.

2) I don't much like the unix-ifying of OS/2 that is happening, but at the same time recognize that is where the new applications are coming from. I will swallow my dislike for unix type structure and conventions in order to get the progress that happens from porting stuff from Linux to OS/2.

3) I have gone from despising YUM/RPM/APM to actually liking RPM. Sort of. As others have discovered, it is almost impossible to keep track of the zillions of DLLs that are used in the various Linux ports, and that seem to change every thirty minutes or so,  without RPM. And it is nice to be able to go to one spot, APM, and update libraries and packages.

4) It seems to me that what we need is for WarpIn and RPM to be able to share (or at least read) the same database, so that each could track what was installed by the other. I don't know what type of database RPM uses, but I do know that the 2-level structure of OS/2 .INI files WarpIN uses is really not sufficient to keep track of applications of any size, so WarpIn really needs a database upgrade anyway.

5) Changes are getting made to basic parts of the LIBC/EMX components that break older applications. XFree86 is an example. So having a "snap shot" of the DLLs used by an application is really necessary now, and will be in the future, for applications to continue running while all the infrastructure is updated. For XFree86 I installed it on a virgin ECS system, zipped up the X11, USR, VAR directory trees and moved the whole thing to AOS in its own location. I believe Dave pointed out the problems with doing that, but I don't see an alternative. So maybe the solution to so put all the packages in RPM, but also provide a zipped copy of the files needed - as installed -  so that  in the future when the "standard" RPM distribution changes enough to break the application, someone can create a separate directory structure with what is needed for that application.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 11, 2019, 05:24:40 pm
I've created two different versions for the install script: anpm-text and run-yum.

The first one adds  text on the new DLL detection page, if packages are missing. The additional text contains a hint how to install missing packages with Arca Noae Package Manager (ANPM). It lets the installation continue. The second one runs yum automatically when packages are missing and package 2 (Support DLLs) is activated. In both versions the support DLLs were removed, for the anpm-text version also the entire package 2.

Existing system DLLs from older packages have to be uninstalled manually with WarpIN. Select package "DOSBox2 Support DLLs" for uninstallation.

Unfortunately it's not possible with WarpIN to run a .cmd file normally. The window is hidden and the output invisible. One has to run WarpIN from a cmd.exe window to see messages that the called commands return. That's also the method how to debug .wis scripts. Additionally, ANPM doesn't provide the feature to accept package names as command line args. See the AN bug tracker (https://mantis.arcanoae.com/view.php?id=2493). Therefore this option is also not possible. After these checks, I've created the anpm-text version, because for the automatic yum execution, error messages would be gobbled.

The included .cmd files require the file DOSBOX0.74_30.03.19.EXE in the same path. Both .cmd files create a file dosbox0.74_2019-05-11.exe.

Changes:
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 11, 2019, 05:43:39 pm
If you still want to provide the system DLLs as support package, I would create a .zip file (zip -9X dosboxsystemdlls dll1 dll2 dll3) and provide that separately.

Then it's a bit clearer that people who unpack that might run into problems later with other packages. But i won't do that.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 11, 2019, 07:12:36 pm
Hi Andreas.

Big thanks for the Warpin scripts. I will test them.


Bye Jochen
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Alex Taylor on May 12, 2019, 12:08:17 am
Unfortunately it's not possible with WarpIN to run a .cmd file normally. The window is hidden and the output invisible. One has to run WarpIN from a cmd.exe window to see messages that the called commands return. That's also the method how to debug .wis scripts.

You can bring a CMD file to the foreground when it's called from WarpIN.  You just have to write the CMD file to do that.  In my ClearType fonts WPI I used this technique when I needed the script to prompt the user for special options.

Code: [Select]
/* Bring the current session to the foreground (so the user can see messages) */
PARSE SOURCE . . me
myname = FILESPEC('NAME',  me )
CALL SysSwitchSession myname
CALL SysSwitchSession me

(This requires REXXUTIL functions to be loaded, obviously.  SysSwitchSession was added in Warp 3 FixPak 35 and Warp 4 FixPak 6. IIRC the double invocation is because in some cases the Window List entry may include the path component, and in others it may not.)

Note, however, that it is not a good idea to make the CMD wait on user input if there is any likelihood that the WPI might need to support CID-mode (headless) install, for obvious reasons.  (The aforementioned ClearType WPI gets away with it because it can't be distributed commercially anyway, so it's extremely unlikely to be called by a CID installer.)
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 12, 2019, 09:51:18 pm
Thanks, Alex. Yes, that works.

I've updated the run-yum version. It contains another REXX file that calls yum.

Update on 2019-05-16: Fixed typo in dosbox-runyum.cmd that prevented the VIO window to become topmost.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 12, 2019, 09:58:00 pm
Note, however, that it is not a good idea to make the CMD wait on user input if there is any likelihood that the WPI might need to support CID-mode (headless) install, for obvious reasons.  (The aforementioned ClearType WPI gets away with it because it can't be distributed commercially anyway, so it's extremely unlikely to be called by a CID installer.)
Yes, that was one reason why I've favored the anpm-text version. Now I think, in a CID case, the .rpm files might be installed before. Then the DLL check might pass and omit calling the dosbox-runyum.cmd.

And I've added the -y parameter to yum in the .wis file. (I don't know how yum would behave in case of an error.)
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 12, 2019, 10:42:47 pm
The new version of run-yum seems to call yum only if no other package is selected. The version from yesterday with direct call of yum without the .cmd file doesn't have this problem. Therefore my favorite is again the anpm-text version.

(I don't understand this behavior. I remember that for NEPMD, all .cmd files being called by separately selectable packages work.)

OK, that was caused by having the DLL package installed in another dir than the rest. It all works now. I've also updated the .wis* file in the .zip file above to use the full path for dosbox-runyum.cmd, but that's not required.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 13, 2019, 10:18:53 am
Wow, this gets better and better ;-)
Thank you all for the support.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: David Graser on May 13, 2019, 03:13:42 pm
Just doodling around. Made a couple of more OS/2 icons based on the other PNGs I created.  The icons can be renamed to match.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 14, 2019, 08:51:23 am
I used Andreas' scripts and David's great icons to build package.
Can somebody else please test it. It looks good to me.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 14, 2019, 06:07:04 pm
Jochen, please correct my name.

On page 1, the trailing period of the last sentence is missing and Warpin should be changed to WarpIN.

Yum is not called for me. I've just tested it on an almost fresh ArcaOS 5.0.1, where sdl120.dll and libcn0.dll (due to an older libc) were not found.

At least the error should be indicated and an instruction how to proceed should pop up.

I'll try to find out what failed in the next days. It has worked for me on the other machine.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 14, 2019, 06:20:44 pm
Oh, I'm very sorry. You are correct. I just copy and paste it from the wrong place, it seems.
When, I get home, I correct it and upload the correct version.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: David Graser on May 14, 2019, 06:35:11 pm
I wonder if uninstalling the previous version is that important  that it should be given it own installation page and that WarpIn should be mentioned to do the uninstaall.

I also attempted to touch up the fulldoxbox icon a little,

After installation, replace the icon with the test.ico to see the minor differences,  Primarily the c: prompt is a little clearer
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Jochen Schäfer on May 14, 2019, 07:41:30 pm
I have replaced the first version with a version with correct attribution.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 14, 2019, 08:04:50 pm
I have replaced the first version with a version with correct attribution.
The file dosbox-runyum.cmd is missing in your package. It should be added to package 2. That's the reason why yum wasn't started. And situations like this have to be reported, as I wrote. I'll improve that version.

Could you please fix also my name here (https://www.os2world.com/forum/index.php/topic,2073.msg21737.html#msg21737)?

Another item: The .txt files should be converted from windows-1252 to ibm-850. The .lang files are used in DOS and already have the correct codepage 850. That can be done with uconv:

uconv -i -c -f windows-1252 -t ibm-850 -o outfile infile
After that, copy outfile over the original encoded infile.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 14, 2019, 08:51:43 pm
I wonder if uninstalling the previous version is that important  that it should be given it own installation page and that WarpIn should be mentioned to do the uninstaall.
Yes, uninstallation should only be necessary, if previously installed files have to be uninstalled. IMO that applies for the system DLLs. Therefore I've added that paragraph on the first page, but it doesn't require an own installation page. You're right, it should be mentioned that, for uninstallation, WarpIN has to be be started. I'll add that.

BTW: The correct case for the name of the installer is: WarpIN.
Title: Re: Discussion about RPM/YUM and Libcn
Post by: Andreas Schnellbacher on May 16, 2019, 12:01:09 am
I've fixed quite some bugs, added the mentioned improvements and more. The encoding changes still have to be done.

Jochen, I'll address you tomorrow (it's now too late for listing details) per PM.