> On Wed, 6 Jan 2010 Peter Naulls wrote:
>
> Alan Buckley wrote:
>
>> The shared unix library itself is provided in the UnixLib package
>> from riscpkg which was installed in !UnixLib. A separate package
>> put the development headers etc in the same place. So if you
>> conflict with the UnixLib package it will cause a problem for
>> all riscpkg packages (and the autobuilder ones) that use the
>> shared unix library as uninstalling UnixLib should cause them
>> all to be uninstalled.
>
> I'm not sure of your reasoning here. Ignoring the NetSurf
> repo for the moment, riscpkg.org of course needs to provide
> a consistent and complete set of packages. As does
> riscos.info, independently. However, given that riscos.info
> contains newer versions of packages (most notably GCC,
> but certainly others in future), there's no reason for
> riscos.info packages not to replace/conflict with them.
> This assumes a resolution of the sul vs SUL naming, which
> we don't yet have.
>
> Remember that the use of !UnixLib at all is particularly
> dated.
The problem is the unixlib package and the !UnixLib it installs
contains the SharedUnixLibrary module. If you conflict with the
unixlib package then all packages that depend on it will be
removed when you uninstall it to install the new
sharedunixlibrary package. You could have a conflict between
gcc4 and the development unixlib package (I'm not sure what
its called at the moment UnixLib-Dev?), but not the unixlib
package.
>
>> Are we going to call the package "sharedunixlibrary" now?
>>
>> If so we need to modify the add-riscpkg script to put this
>> in the depends when the -unixlib option is used instead of
>> UnixLib.
>
> Understood. I'm still sitting on this one. Having again
> reviewed the setup on riscpkg.org and NetSurf, I'm
> prepared to be convinced that upper/camelcase is going to
> be better for RISC OS. I still have a nasty feeling
> that there's some hidden problem here
I think it should be camelcase or lowercase, not upper case
for all letters.
I can't think of a problem, but you know the system better.
>
> If so, then this requires renaming of virtually all packages,
> although it might be automatic for some types of libraries.
> And given the complexity and surprising number of names involved
> in one particular package, this is something I want to consider
> further. As I mentioned earlier, an uppercase name would
> be (in 95% of cases) also the name of a matching wiki
> page for that app.
>
The immediate requirement would be just for the main dependencies,
SharedUnixLibrary, DRenderer etc. The others could be renamed as
they are rebuilt, though this will cause the need for an uninstall
of the old package and install of the new to upgrade a package.
It would be better to have it sorted out before we started
packaging shared libraries.
I don't have the knowledge of the number and complexity of the names
for the packages, so I'm happy to go by what can sensibly be
achieved rather than sticking to my preference.
>>>
>>> It allows virtual packages:
>
>>>
>> Thanks, this link makes it clear. This would seem to be a simple way
>> to solve the problem if it had been implemented.
>
> Do you think that this is something you can do? If nothing else,
> libpkg's propagation of errors needs much work, so we do not get
> generic errors present to the app (such as when I had a $ in the
> filename, confusing the unzipping).
>
I'm not sure this is something I can do, I've looked at the code
to make it compile on gcc4 and to use it in my package manager,
but not in sufficient detail to make major changes.
I completely agree about the error propagation, I've spent many
hours trying to track down exactly what's wrong with a package.
I will bear this in mind, and if I get a chance have a more
detailed look at libpkg, but it's not likely to happen for
a while.
Regards,
Alan
_________________________________________________________________
View your other email accounts from your Hotmail inbox. Add them now.
http://clk.atdmt.com/UKM/go/186394592/direct/01/
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
