Not signed in (Sign In)

Choose a language

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

Support and General Discussion: Different architechtues, akin to different versions?

Bottom of Page

1 to 5 of 5

  1.  
    • CommentAuthorsdellysse
    • CommentTimeMay 4th 2008
     # 1
    A concept that was probably not thought of when the distrobution was created: multiple archs available to single machine. The main example (my current problem) is the x86 and the x86_64 editions of software. There is no doubt that 64bit computing is the natural evolution of the personal computer, and it needs to be addressed. A concurrent arch system would allow people to run mostly 64bit software with the needed exceptions (such as Firefox) running along side with minimal confusion.

    I propose:
    * an extension to the version directory naming scheme
    ** example: /Programs/Firefox/3.0b5:x86 or /Programs/Firefox/3.0b5:x86_64 ((probably wont work due to incompatabilites, but very clean))
    ** or: /Programs/Firefox/x86--3.0b5 or /Programs/Firefox/x86_64--3.0b5 ((a little cluttered but would have easy regexp matching))
    ** or: /Programs/Firefox/3.0b5(x86) or /Programs/Firefox/3.0b5(x86_64)

    Any opinions?
    • CommentAuthorshevegen
    • CommentTimeMay 4th 2008 edited
     # 2
    My opinion (and I am no developer) is that these look ugly:

    Version:x86
    Version:x86_64

    Right now the Gobolinux programs will be installed to /Programs/Name/Version and this new change would break this scheme.

    I believe you maybe refer to a DualCore 64 system which also runs 32 bit software? For such apps I think it would be better to have a file denote which architecture a given package runs on. (This is perhaps already the case on Gobolinux, I am not sure, inside Resources/ directory ).

    The graphical manager Manager could display such information to the user as well with a little icon or notice (32 or 64 or whatever architecture that package belongs to). *hint hint to Manager developer*
    • CommentAuthorsdellysse
    • CommentTimeMay 11th 2008
     # 3
    I understand the aversion to breaking the scheme, but what is the point of having an alternative system without flexibility? Having a file denoting a different architecture would be nice but it wouldn't allow for concurrent versioning, one of the biggest features of gobo.

    As for Manager, this is my personal opinion, any graphical system tool should simply be a wrapper around the command line versions, with a little abstractions due to the nature of it. Having the Manager know what arch a certain recipe/package and not being able to know on the CLI is detrimental to the UNIX philosophy.
    • CommentAuthorshevegen
    • CommentTimeMay 12th 2008 edited
     # 4
    I understand the aversion to breaking the scheme, but what is the point of having an alternative system without flexibility?

    I am not sure what flexibility you aim for other than breaking the current scheme :)
    The Gobolinux system isn't THAT flexible either, it has to rely on the authors too. And I think without the legacy symlinks it would not
    work as smooth.

    But I would agree if you state that a flexible system is important to have, after all the autotools allow for some flexibility.
  5.  # 5
    I do see this as a good idea but can't see any way in which it could be implemented with ease. But it is a good idea and one to take into consideration.

1 to 5 of 5

  1.