Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
For the rest of the community -- Where are you putting tde? It would just make sense to set a community-wide standard. Yes, I know that the location is irrelevant and can be obtained by the standard environment files, but we recently had a rebuild of 3.5.12 that moved from /opt/kde to /opt/kde3. That's fine, but depending upon the repo you hit to pull files from, your system would break due to install location differences in the various packages.
I don't have any hard feelings either way for any single location, but if it is all the same, then if possible, I would like to see a standard that all packagers could reference. Of course you don't have to use it, but if there is a standard install, the balance of builds will migrate to it over time.
What says the team?
/opt/trinity /opt/tde /opt/tde_ver (ver being a 2 or 3-digit version: eg. 13 or 313) /opt/other_suggestions?
Personally for me, /opt/tde works :)
(/opt/trinity is probably my fault on arch anyway :)
On Wed, Feb 22, 2012 at 18:19, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
For the rest of the community -- Where are you putting tde? It would just make sense to set a community-wide standard. Yes, I know that the location is irrelevant and can be obtained by the standard environment files, but we recently had a rebuild of 3.5.12 that moved from /opt/kde to /opt/kde3. That's fine, but depending upon the repo you hit to pull files from, your system would break due to install location differences in the various packages.
I don't have any hard feelings either way for any single location, but if it is all the same, then if possible, I would like to see a standard that all packagers could reference. Of course you don't have to use it, but if there is a standard install, the balance of builds will migrate to it over time.
What says the team?
/opt/trinity /opt/tde /opt/tde_ver (ver being a 2 or 3-digit version: eg. 13 or 313) /opt/other_suggestions?
Personally for me, /opt/tde works :)
(/opt/trinity is probably my fault on arch anyway :)
I have standardized around /opt/tde; all my trinity packaging macros use it. /me points to home:bravoall1552:tde3.5.13/tde-filesystem
But my spec files are not meant to be backwards compatible with any system < 11.4 on openSUSE; meaning that I don't support upgrading from /opt/kde3. :|
On 02/22/2012 07:05 PM, Robert Xu wrote:
I have standardized around /opt/tde; all my trinity packaging macros use it. /me points to home:bravoall1552:tde3.5.13/tde-filesystem
proof great minds think alike:
But my spec files are not meant to be backwards compatible with any system < 11.4 on openSUSE; meaning that I don't support upgrading from /opt/kde3. :|
I will have to try tde on my 11.4 install. I have to dump my current 11.4 and reinstall anyway. How is it working?
On Wed, Feb 22, 2012 at 20:10, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/22/2012 07:05 PM, Robert Xu wrote:
I have standardized around /opt/tde; all my trinity packaging macros use it. /me points to home:bravoall1552:tde3.5.13/tde-filesystem
proof great minds think alike:
But my spec files are not meant to be backwards compatible with any system < 11.4 on openSUSE; meaning that I don't support upgrading from /opt/kde3. :|
I will have to try tde on my 11.4 install. I have to dump my current 11.4 and reinstall anyway. How is it working?
I have tdelibs finally working - I decided to scrap the patches in the hopes that if bugs occur, I'll port them. (Serghei, was upower pushed?) tdebase is sitting in my local GIT; but build.o.o is refusing to cooperate with me, so I can't push right now.
On Wednesday 22 February 2012 06:19:15 pm David C. Rankin wrote:
Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
For the rest of the community -- Where are you putting tde?
/usr/local
/usr/local most certainly not. Personally i am using /usr as i have no KDE4 installed. For the others i would imagine /opt/trinity as per instructions ... cmon .... 4 more letters is not really hard yakka.
Jay
On Thu, Feb 23, 2012 at 1:53 AM, Baho Utot baho-utot@columbus.rr.comwrote:
On Wednesday 22 February 2012 06:19:15 pm David C. Rankin wrote:
Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
For the rest of the community -- Where are you putting tde?
/usr/local
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 02/22/2012 08:01 PM, Jay wrote:
/usr/local most certainly not. Personally i am using /usr as i have no KDE4 installed. For the others i would imagine /opt/trinity as per instructions ... cmon .... 4 more letters is not really hard yakka.
Jay
...depends on how old your fingers are... :)
On 02/22/2012 09:01 PM, Jay wrote:
/usr/local most certainly not. Personally i am using /usr as i have no KDE4 installed. For the others i would imagine /opt/trinity as per instructions ... cmon .... 4 more letters is not really hard yakka.
Jay
On Thu, Feb 23, 2012 at 1:53 AM, Baho Utot <baho-utot@columbus.rr.com mailto:baho-utot@columbus.rr.com> wrote:
On Wednesday 22 February 2012 06:19:15 pm David C. Rankin wrote: > Archers, All, > > Currently, Arch installs trinity to /opt/trinity. Personally, I would > like to move the default install to /opt/tde. Two reasons: (1) most > important -- less typing; (2) the tradition of the install being in > /opt/kde, why not standardize around /opt/tde? > > For the rest of the community -- Where are you putting tde? /usr/local --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net <mailto:trinity-devel-unsubscribe@lists.pearsoncomputing.net> For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net <mailto:trinity-devel-help@lists.pearsoncomputing.net> Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Isn't it easier to move to /usr from /usr/local?
A few simple sed's and the environment is fixed.
Ever look at startkde.ah or starttrinity.sh
On 23 February 2012 08:41, Baho Utot baho-utot@columbus.rr.com wrote:
On 02/22/2012 09:01 PM, Jay wrote:
/usr/local most certainly not. Personally i am using /usr as i have no KDE4 installed. For the others i would imagine /opt/trinity as per instructions ... cmon .... 4 more letters is not really hard yakka.
Jay
On Thu, Feb 23, 2012 at 1:53 AM, Baho Utot baho-utot@columbus.rr.com wrote:
On Wednesday 22 February 2012 06:19:15 pm David C. Rankin wrote:
Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
For the rest of the community -- Where are you putting tde?
/usr/local
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Isn't it easier to move to /usr from /usr/local?
A few simple sed's and the environment is fixed.
Ever look at startkde.ah or starttrinity.sh
Again:
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs >to be safe from being overwritten when the system software is updated. It may be used for programs >and data that are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to >replace or upgrade software in /usr"
I use /usr/ for my packages installed from my repos. stuff in /usr/local is things I manually install, or keep back because I need them.
that is not a place for packages.
Calvin
On 02/23/2012 08:58 AM, Calvin Morrison wrote:
On 23 February 2012 08:41, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/22/2012 09:01 PM, Jay wrote:
/usr/local most certainly not. Personally i am using /usr as i have no KDE4 installed. For the others i would imagine /opt/trinity as per instructions ... cmon .... 4 more letters is not really hard yakka.
Jay
On Thu, Feb 23, 2012 at 1:53 AM, Baho Utotbaho-utot@columbus.rr.com wrote:
On Wednesday 22 February 2012 06:19:15 pm David C. Rankin wrote:
Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
For the rest of the community -- Where are you putting tde?
/usr/local
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Isn't it easier to move to /usr from /usr/local?
A few simple sed's and the environment is fixed.
Ever look at startkde.ah or starttrinity.sh
Again:
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs>to be safe from being overwritten when the system software is updated. It may be used for programs>and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to>replace or upgrade software in /usr"
I use /usr/ for my packages installed from my repos. stuff in /usr/local is things I manually install, or keep back because I need them.
that is not a place for packages.
Really?
trinity is not software locally installed by the local system admin?
/usr/local IS for software installed after the base distribution. Since trinity is not installed by default in a lot of distros, onw should place that sofware into /usr/local What will you do when it is or how is distros supposed to pick it up if it won't work when installed into /usr?
Installation into /usr _should_ be the goal not playing with installation into /opt.
Any way it's not an issue with me as I will continue on.....onward on my own path installing into /usr/local, since it is your way or no way.
/usr/local simplifes the install and keeps it separate from the distro stuff (Arch soon to be my own scratch built ) and does not interfere with QT4 and KDE4 and without all the mumbo jumbo associated with the install into /opt. The build goes better and the install goes better.
Really?
trinity is not software locally installed by the local system admin?
Right now it is - but very soon it will be installed from mirrors, via the package manager; users are expecting /usr/local to be stuff installed by them not the package manager
/usr/local IS for software installed after the base distribution. Since trinity is not installed by default in a lot of distros, onw should place that sofware into /usr/local
Just because it is not installed by default doesn't mean it shouldn't operate as a normal package.
What will you do when it is or how is distros supposed to pick it up if it won't work when installed into /usr?
That is for upstream to solve. as packagers we are just here to package. Trinity is continuing to work on the renaming effort - until it is finished I do not want any conflicts.
Installation into /usr _should_ be the goal not playing with installation into /opt.
Any way it's not an issue with me as I will continue on.....onward on my own path installing into /usr/local, since it is your way or no way.
I have offered many a time to have you join up and you consistently refuse.
/usr/local simplifes the install and keeps it separate from the distro stuff (Arch soon to be my own scratch built ) and does not interfere with QT4 and KDE4 and without all the mumbo jumbo associated with the install into /opt. The build goes better and the install goes better.
Have you even bothered to read the arch package guidelines which so profess like a holy book?
"Packages should never be installed to /usr/local"
"/opt/{pkg}: Large self-contained packages such as Java, etc."
I consider trinity a large self contained project.
Furthermore /opt/ is a bit more of a saner solution because it helps keep everything seperate - this is something I think is good. especially while packages are still in beta stages.
When the time comes to merge into the archlinux official packages, we can move it where they wish. I do think they will prefer /opt/
Calvin Morrison
On 02/23/2012 09:35 AM, Calvin Morrison wrote:
Really?
trinity is not software locally installed by the local system admin?
Right now it is - but very soon it will be installed from mirrors, via the package manager; users are expecting /usr/local to be stuff installed by them not the package manager
/usr/local IS for software installed after the base distribution. Since trinity is not installed by default in a lot of distros, onw should place that sofware into /usr/local
Just because it is not installed by default doesn't mean it shouldn't operate as a normal package.
What will you do when it is or how is distros supposed to pick it up if it won't work when installed into /usr?
That is for upstream to solve. as packagers we are just here to package. Trinity is continuing to work on the renaming effort - until it is finished I do not want any conflicts.
Installation into /usr _should_ be the goal not playing with installation into /opt.
Any way it's not an issue with me as I will continue on.....onward on my own path installing into /usr/local, since it is your way or no way.
I have offered many a time to have you join up and you consistently refuse.
No I don't refuse, since you folks are going in whatever way quite blindly and I don't wish to follow forces me to travel another path. What I do works for me and if it can benifit others then good, use what I have. It was you folks that refused to use what I have. What you have just doesn't work for me or is horribly broken which does'nt help me at all.
/usr/local simplifes the install and keeps it separate from the distro stuff (Arch soon to be my own scratch built ) and does not interfere with QT4 and KDE4 and without all the mumbo jumbo associated with the install into /opt. The build goes better and the install goes better.
Have you even bothered to read the arch package guidelines which so profess like a holy book?
"Packages should never be installed to /usr/local"
That is from Arch linux vantage point. ie from a distro point. I am looking at it from a local system admin point which from the LSB points installation into /usr/local
"/opt/{pkg}: Large self-contained packages such as Java, etc."
I consider trinity a large self contained project.
Furthermore /opt/ is a bit more of a saner solution because it helps keep everything seperate - this is something I think is good. especially while packages are still in beta stages.
When the time comes to merge into the archlinux official packages, we can move it where they wish. I do think they will prefer /opt/
Where is KDE4 installed to on a arch linux install?
cmake ../${pkgname}-${pkgver} \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_SKIP_RPATH=ON \ -DKDE_DISTRIBUTION_TEXT='Arch Linux' \ -DCMAKE_INSTALL_PREFIX=/usr \ -DSYSCONF_INSTALL_DIR=/etc \ -DHTML_INSTALL_DIR=/usr/share/doc/kde/html \ -DKDE_DEFAULT_HOME='.kde4' \ -DWITH_FAM=OFF make
Oh look it installs into /usr just where tde should also install to .
The issue is that because of conflicts, tde can not be installed to /usr so the arch devs simply can not install it there. Since it is _not_ installed from a distro... I believe that LSB states it is a locally installed package that should go into /usr/local. After all it is local to the boxen in question. I have kde-3.5.10 and tde 3.5.13 installed on a single slackware-12.2 boxen with tde installed to /usr/local. Both easily work.
Any way I don't see arch picking up tde for a long time.
No I don't refuse, since you folks are going in whatever way quite blindly and I don't wish to follow forces me to travel another path. What I do works for me and if it can benifit others then good, use what I have. It was you folks that refused to use what I have. What you have just doesn't work for me or is horribly broken which does'nt help me at all.
That is from Arch linux vantage point. ie from a distro point. I am looking at it from a local system admin point which from the LSB points installation into /usr/local
Which is quite illogical - because we are creating packages. therefore we need to follow the view point of packagers. If i was just building then installing without packages - it would go within /usr/local/. but I'm not. I am creating packages for archlinux users who want to install binary packages with no conflicts to KDE4 or other archlinux
we are packaging for Archlinux, therefore we embrace and take the standpoint of Arch.
Where is KDE4 installed to on a arch linux install?
cmake ../${pkgname}-${pkgver} \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_SKIP_RPATH=ON \ -DKDE_DISTRIBUTION_TEXT='Arch Linux' \ -DCMAKE_INSTALL_PREFIX=/usr \ -DSYSCONF_INSTALL_DIR=/etc \ -DHTML_INSTALL_DIR=/usr/share/doc/kde/html \ -DKDE_DEFAULT_HOME='.kde4' \ -DWITH_FAM=OFF make
Oh look it installs into /usr just where tde should also install to .
We != kde.
I am totally okay with our non-binary, documentation files going into /usr/share/doc, but at this point it is still less of a hassle ( and something easily changed ) to install to /opt/trinity/
The issue is that because of conflicts, tde can not be installed to /usr so the arch devs simply can not install it there.
exactly.
Since it is _not_ installed from a distro... I believe that LSB states it is a locally installed package that should go into /usr/local.
Again, you have some skewed point of view regarding our packages. they will be binary packages, that installed via a repository in a completely normal way. nothing local about it.
Any way I don't see arch picking up tde for a long time.
Certainly not with that attitude.
Calvin Morrison
On 02/23/2012 10:17 AM, Calvin Morrison wrote:
No I don't refuse, since you folks are going in whatever way quite blindly and I don't wish to follow forces me to travel another path. What I do works for me and if it can benifit others then good, use what I have. It was you folks that refused to use what I have. What you have just doesn't work for me or is horribly broken which does'nt help me at all.
That is from Arch linux vantage point. ie from a distro point. I am looking at it from a local system admin point which from the LSB points installation into /usr/local
Which is quite illogical - because we are creating packages. therefore we need to follow the view point of packagers. If i was just building then installing without packages - it would go within /usr/local/. but I'm not. I am creating packages for archlinux users who want to install binary packages with no conflicts to KDE4 or other archlinux
we are packaging for Archlinux, therefore we embrace and take the standpoint of Arch.
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
Where is KDE4 installed to on a arch linux install?
cmake ../${pkgname}-${pkgver} \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_SKIP_RPATH=ON \ -DKDE_DISTRIBUTION_TEXT='Arch Linux' \ -DCMAKE_INSTALL_PREFIX=/usr \ -DSYSCONF_INSTALL_DIR=/etc \ -DHTML_INSTALL_DIR=/usr/share/doc/kde/html \ -DKDE_DEFAULT_HOME='.kde4' \ -DWITH_FAM=OFF makeOh look it installs into /usr just where tde should also install to .
We != kde.
Really?
I am totally okay with our non-binary, documentation files going into /usr/share/doc, but at this point it is still less of a hassle ( and something easily changed ) to install to /opt/trinity/
The issue is that because of conflicts, tde can not be installed to /usr so the arch devs simply can not install it there.
exactly.
Since it is _not_ installed from a distro... I believe that LSB states it is a locally installed package that should go into /usr/local.
Again, you have some skewed point of view regarding our packages. they will be binary packages, that installed via a repository in a completely normal way. nothing local about it.
Any way I don't see arch picking up tde for a long time.
Certainly not with that attitude.
Dude.... tde is not ready for prime time.
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
We != kde.
Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
On 02/23/2012 10:32 AM, Calvin Morrison wrote:
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
We != kde.
Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
Would you use it in a corperate environment?
I think not.
On 23 February 2012 10:45, Baho Utot baho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote:
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
We != kde.
Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Agreed that which distro to use in an enterprise environment excludes quite a few distros.
A better question is whether Trinity is suitable for the enterprise. At the moment I humbly say no, but only because we need to address many bugs. Even after we resolve all build and packaging bug reports, we have many nuisance usability bugs that need attention. Us geeks can overlook or work around those types of bugs, but not people using computers in an enterprise environment.
If compatibility with Windows is a requirement then we would need to evaluate in real time how Trinity functions in such an environment. As long as Trinity can use underlying layers, such as Samba or LDAP, then Trinity could be used. The one challenge will always be MS Office, but that is an app question and not a desktop question.
If Windows and MS Office compatibility are secondary requirements, then LibreOffice likely will suffice for MS Office. Then the question is whether Trinity is a palatable desktop for such business users. I believe Trinity is palatable for such environments but not until we eliminate most of the bugs reported, which means R14.
I have been working hard to see R14 arrive. :)
Whether Trinity is suitable for the enterprise is something I'd like us to explore --- but after R14.
Darrell
On 02/23/2012 10:47 AM, Calvin Morrison wrote:
On 23 February 2012 10:45, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote:
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
We != kde.
Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
You skirt the issue We are not talking arch here
Would you use tde in a corperate environment?
On 23 February 2012 11:31, Baho Utot baho-utot@columbus.rr.com wrote:
On 02/23/2012 10:47 AM, Calvin Morrison wrote:
On 23 February 2012 10:45, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote:
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
We != kde.
Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
You skirt the issue We are not talking arch here
Would you use tde in a corperate environment?
No. I would not use Trinity Desktop Environment in a corporate environment. I would not use GNOME 3.2 or KDE 4.8. I will not use them sam I am.
Calvin
On 02/23/2012 11:35 AM, Calvin Morrison wrote:
On 23 February 2012 11:31, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:47 AM, Calvin Morrison wrote:
On 23 February 2012 10:45, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote:
You are not an arch dev. Therefore tde is an addon package by others not indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
> We != kde.
Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
You skirt the issue We are not talking arch here
Would you use tde in a corperate environment?
No. I would not use Trinity Desktop Environment in a corporate environment. I would not use GNOME 3.2 or KDE 4.8. I will not use them sam I am.
Calvin
So I was correct. Why the game?
This is what turns me off to trinity, this just looks like game playing.
There is a lot of work to be done. Focus on that.
On 23 February 2012 11:49, Baho Utot baho-utot@columbus.rr.com wrote:
On 02/23/2012 11:35 AM, Calvin Morrison wrote:
On 23 February 2012 11:31, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:47 AM, Calvin Morrison wrote:
On 23 February 2012 10:45, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote:
> > You are not an arch dev. Therefore tde is an addon package by others > not > indorsed by arch linux.
endorsed'
And yes - I am not "endorsed", or a dev. I am just a guy packaging stuff for it. many many many many people do this - it is called the Arch User Repository. it allows anyone to post package spec files so we all can use them. packages that are immensely popular in the AUR (as noted by the vote system) are often then bumped into official repositories.
The very spirit of Archlinux is to utilize tools like the AUR, using "addon" - aka unoffical packages.
you don't seem like much of an archer, and I don't really get what you are trying to say here. We are working on these packages now, so that users can use Trinity now, and maybe we can gain a following in that market, and then maybe get included in real repositories in the future.
>> We != kde. > > > Really?
wat.
Using TDE as my "prime time" desktop since 2010, Calvin
Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
You skirt the issue We are not talking arch here
Would you use tde in a corperate environment?
No. I would not use Trinity Desktop Environment in a corporate environment. I would not use GNOME 3.2 or KDE 4.8. I will not use them sam I am.
Calvin
So I was correct. Why the game?
This is what turns me off to trinity, this just looks like game playing.
There is a lot of work to be done. Focus on that.
You've changed topics many times and I'm not sure how this has anything to do with packaging trinity for arch.
it's hard to focus with so much offtopic messages bothering my mail account ;)
Calvin
On 23 February 2012 11:49, Baho Utot baho-utot@columbus.rr.com wrote:
On 02/23/2012 11:35 AM, Calvin Morrison wrote:
On 23 February 2012 11:31, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:47 AM, Calvin Morrison wrote:
On 23 February 2012 10:45, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote: >> >> You are not an arch dev. Therefore tde is an addon package by >> others >> not >> indorsed by arch linux. > > endorsed' > > And yes - I am not "endorsed", or a dev. I am just a guy packaging > stuff for it. many many many many people do this - it is called the > Arch User Repository. it allows anyone to post package spec files > so > we all can use them. packages that are immensely popular in the AUR > (as noted by the vote system) are often then bumped into official > repositories. > > The very spirit of Archlinux is to utilize tools like the AUR, > using > "addon" - aka unoffical packages. > > you don't seem like much of an archer, and I don't really get what > you > are trying to say here. We are working on these packages now, so > that > users can use Trinity now, and maybe we can gain a following in > that > market, and then maybe get included in real repositories in the > future. > >>> We != kde. >> >> >> Really? > > wat. > > Using TDE as my "prime time" desktop since 2010, > Calvin > Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
You skirt the issue We are not talking arch here
Would you use tde in a corperate environment?
No. I would not use Trinity Desktop Environment in a corporate environment. I would not use GNOME 3.2 or KDE 4.8. I will not use them sam I am.
Calvin
So I was correct. Why the game?
This is what turns me off to trinity, this just looks like game playing.
There is a lot of work to be done. Focus on that.
You've changed topics many times and I'm not sure how this has anything to do with packaging trinity for arch.
it's hard to focus with so much offtopic messages bothering my mail account ;)
Calvin
Take it as a challenge: Why exactly would you choose Window$ over a FOSS solution for a corporate environment? Quantify the reasons and file enhancement requests to get them fixed.
Tim
Take it as a challenge: Why exactly would you choose Window$ over a FOSS solution for a corporate environment? Quantify the reasons and file enhancement requests to get them fixed.
Tim
I do not use Linux because it does not integrate with the rest of the world. At my workplace I am required to send and receive document files like xml, docx and others that are not supported well by linux. I need to send these internally, but more importantly externally.
If everyone internally uses LibreOffice - great. the problem is that customers are using windows, and we need to be able to work with them.
This is not something Trinity Desktop can provide.
Apart from that, group integration needs to be stabalized. the caldav integration crashes for me. Bugs have been filed #631.
if i was forced to pick one desktop it would be Trinity Desktop, or KDE3 on a very old version of RHEL.
Calvin
Take it as a challenge: Why exactly would you choose Window$ over a FOSS solution for a corporate environment? Quantify the reasons and file enhancement requests to get them fixed.
Tim
I do not use Linux because it does not integrate with the rest of the world. At my workplace I am required to send and receive document files like xml, docx and others that are not supported well by linux. I need to send these internally, but more importantly externally.
If everyone internally uses LibreOffice - great. the problem is that customers are using windows, and we need to be able to work with them.
This is not something Trinity Desktop can provide.
Of course. I was referring to usability/functionality/stability problems in FOSS, and was not attemting to solve vendor lock-in issues.
Apart from that, group integration needs to be stabalized. the caldav integration crashes for me. Bugs have been filed #631.
Fixed. Coincidentally I was working on that bug earlier today and just pushed the patches in a few minutes ago.
Tim
On 23 February 2012 12:55, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Take it as a challenge: Why exactly would you choose Window$ over a FOSS solution for a corporate environment? Quantify the reasons and file enhancement requests to get them fixed.
Tim
I do not use Linux because it does not integrate with the rest of the world. At my workplace I am required to send and receive document files like xml, docx and others that are not supported well by linux. I need to send these internally, but more importantly externally.
If everyone internally uses LibreOffice - great. the problem is that customers are using windows, and we need to be able to work with them.
This is not something Trinity Desktop can provide.
Of course. I was referring to usability/functionality/stability problems in FOSS, and was not attemting to solve vendor lock-in issues.
Apart from that, group integration needs to be stabalized. the caldav integration crashes for me. Bugs have been filed #631.
Fixed. Coincidentally I was working on that bug earlier today and just pushed the patches in a few minutes ago.
Tim
You rock! :-)
Usability is not our main issue in corporate environments - rather integration I think.
Take it as a challenge: Why exactly would you choose Window$ over a FOSS solution for a corporate environment? Quantify the reasons and file enhancement requests to get them fixed.
Which basically was my point in my previous post. :) I would like to explore this topic after R14. That is, what do we need to do?
My daily usage in my home office is not within a classic enterprise environment, but I envision various work flows based upon recent work contracts. Off site in my home office I use my KDE3 desktop running VirtualBox to run Windows apps, mostly FrameMaker. I use KMail and configure that app for any contract related email address assigned to me. I browse the web for research through Firefox on my normal KDE3 desktop. I'm resistant to using instant messaging apps as I dislike such interruptions. I'm known for unplugging my phone ringer when I don't want to be interrupted. :) Thus in my limited manner I am able to use KDE3 as my primary desktop with no issues.
Resolving about two dozen bug reports will allow me to seamlessly migrate to Trinity. That is very much my goal with R14. :)
Working on site is more challenging. A recent client uses the full MS Office suite, which includes Outlook and Communicator. As long as KMail could connect to the Exchange back server, I'm guessing I could continue using KMail. Does KMail support that?
I don't know whether KOrganizer could be used to interface with the Outlook scheduling back end. Does KOrganizer do that?
Last I looked none of the Trinity IM apps supported the protocol used by Communicator. Please update me if I'm wrong.
On site I could run all of that in a virtual machine --- if the IT people let me. More than likely most IT people will require me to use their preconfigured workstations and software because of lockdown requirements. That's life in the contracting world. Working on site is quite different from working off site. :) A more open minded IT staff might let me use my own OS and desktop, but the direct line of people I am contracted expect me to use the in-house software --- IM, email, scheduling, etc. As long as I can interface with their software and back end apps and servers, they probably would not care. The unknown is whether I can connect in that manner.
Outside the Windows perspective is a different conversation. For me the only speed bump to using Trinity in an enterprise environment are the open bug reports. I write that from the perspective of other users, not me who is more computer savvy than the type of people I tend to contract with. We'll get through those bugs in the upcoming weeks. Eliminating those bugs leaves only the questions about interfacing with standard office apps and back ends. Can we get there? I don't know but I'd like us to explore. Perhaps that could be an R15 goal?
Darrell
On 02/23/2012 11:51 AM, Calvin Morrison wrote:
On 23 February 2012 11:49, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 11:35 AM, Calvin Morrison wrote:
On 23 February 2012 11:31, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:47 AM, Calvin Morrison wrote:
On 23 February 2012 10:45, Baho Utotbaho-utot@columbus.rr.com wrote:
On 02/23/2012 10:32 AM, Calvin Morrison wrote: >> You are not an arch dev. Therefore tde is an addon package by others >> not >> indorsed by arch linux. > endorsed' > > And yes - I am not "endorsed", or a dev. I am just a guy packaging > stuff for it. many many many many people do this - it is called the > Arch User Repository. it allows anyone to post package spec files so > we all can use them. packages that are immensely popular in the AUR > (as noted by the vote system) are often then bumped into official > repositories. > > The very spirit of Archlinux is to utilize tools like the AUR, using > "addon" - aka unoffical packages. > > you don't seem like much of an archer, and I don't really get what you > are trying to say here. We are working on these packages now, so that > users can use Trinity now, and maybe we can gain a following in that > market, and then maybe get included in real repositories in the > future. > >>> We != kde. >> >> Really? > wat. > > Using TDE as my "prime time" desktop since 2010, > Calvin > Would you use it in a corperate environment?
I think not.
Okay this is just offtopic. No I would not use Arch Linux in a corporate environment, it is bleeding edge and not stable. In a corporate environment I would likely deploy a windows based system.
Calvin
You skirt the issue We are not talking arch here
Would you use tde in a corperate environment?
No. I would not use Trinity Desktop Environment in a corporate environment. I would not use GNOME 3.2 or KDE 4.8. I will not use them sam I am.
Calvin
So I was correct. Why the game?
This is what turns me off to trinity, this just looks like game playing.
There is a lot of work to be done. Focus on that.
You've changed topics many times and I'm not sure how this has anything to do with packaging trinity for arch.
it's hard to focus with so much offtopic messages bothering my mail account ;)
Calvin
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Ah OK
I will bother you no more
Please remove all my access to trinydesktop
Where is KDE4 installed to on a arch linux install?
Oh look it installs into /usr just where tde should also install to .
The issue is that because of conflicts, tde can not be installed to /usr so the arch devs simply can not install it there. Since it is _not_ installed from a distro... I believe that LSB states it is a locally installed package that should go into /usr/local. After all it is local to the boxen in question. I have kde-3.5.10 and tde 3.5.13 installed on a single slackware-12.2 boxen with tde installed to /usr/local. Both easily work.
The root issue here is not where each individual wants to install Trinity, or where upstream distro maintainers and packagers should install Trinity, but to ensure there never is a conflict with other packages.
The sole thorn in our side is and always will be KDE4. Anybody packaging Trinity for a distro that includes KDE4 needs to work around where KDE4 gets installed. If the upstream maintainers are installing KDE4 to /usr, then Trinity has to be installed elsewhere. If the upstream maintainers are installing KDE4 to someplace other than /usr, then Trinity can be installed to /usr.
Anybody who controls the distro and decides that KDE4 is not an option can install Trinity to /usr. Most of us do not control those decisions.
One thing is clear: as a team we do a poor job testing Trinity for conflicts with KDE4. I don't care what KDE4 developers think about Trinity, but I don't want them accusing us of sloppy programming or packaging. Testing Trinity for potential KDE4 conflicts needs a much higher priority for all of us. That does not mean installing to /opt or /usr/local merely to avoid conflicts in /usr/bin and /usr/lib, but actually testing both desktops in real time.
Build your packages where you want according to your distro or personal guidelines, but let's focus on the real challenge of producing a robust Trinity. :)
Darrell
On 02/23/2012 10:52 AM, Darrell Anderson wrote:
Where is KDE4 installed to on a arch linux install?
Oh look it installs into /usr just where tde should also install to .
The issue is that because of conflicts, tde can not be installed to /usr so the arch devs simply can not install it there. Since it is _not_ installed from a distro... I believe that LSB states it is a locally installed package that should go into /usr/local. After all it is local to the boxen in question. I have kde-3.5.10 and tde 3.5.13 installed on a single slackware-12.2 boxen with tde installed to /usr/local. Both easily work.
The root issue here is not where each individual wants to install Trinity, or where upstream distro maintainers and packagers should install Trinity, but to ensure there never is a conflict with other packages.
The sole thorn in our side is and always will be KDE4. Anybody packaging Trinity for a distro that includes KDE4 needs to work around where KDE4 gets installed. If the upstream maintainers are installing KDE4 to /usr, then Trinity has to be installed elsewhere. If the upstream maintainers are installing KDE4 to someplace other than /usr, then Trinity can be installed to /usr.
Anybody who controls the distro and decides that KDE4 is not an option can install Trinity to /usr. Most of us do not control those decisions.
One thing is clear: as a team we do a poor job testing Trinity for conflicts with KDE4. I don't care what KDE4 developers think about Trinity, but I don't want them accusing us of sloppy programming or packaging. Testing Trinity for potential KDE4 conflicts needs a much higher priority for all of us. That does not mean installing to /opt or /usr/local merely to avoid conflicts in /usr/bin and /usr/lib, but actually testing both desktops in real time.
I agree with this, but see below.
Build your packages where you want according to your distro or personal guidelines, but let's focus on the real challenge of producing a robust Trinity. :)
Darrell
The reason that all of this is an issue is just because you are not installing into /usr
Let explain
This works for arch or distros using pacman only
I create my PKGBUILDS to install into /usr. When a user is using KDE4 that creates an issues as we all know. I now that the location problem
So I using pacman install the exact same packages relocated to /usr/local using pacman to do the relocation. Pacman handles this without error and the result is that those same packages work in an environment that has KDE4 or on that doesn't, its's the same binary package , I am not requried to change anything. And I only have one set of binary packages. When the conflicts are solved I don't have to change my build script as well, just build and go. Double win.
Now part II
When using pacman pacman will not overwrite a file that is already installed and will complain about the file already existing. So now to get a list os files that conflict with KDE4 all one needs to do is to build the packages into /usr and attempt to install them on a system with nKDE4 and bingo you have a list of those conflicts. That gives you what needs to be renamed all very easy done.
This won't give you all the other issues but at least one has a list of files that have the same name and installed as in KDE4.
This is central to part of the problem to move ahead and finish this project. How is the rename to be completed if no ones knows what needs to be done?
trinity is not software locally installed by the local
system admin?
Right now it is - but very soon it will be installed from mirrors, via the package manager; users are expecting /usr/local to be stuff installed by them not the package manager
/usr/local is for the user. What users want to do with their /usr/local is for them to decide.
Upstream maintainers are not supposed to install anything in /usr/local. When software is provided by upstream providers as part of a distribution's package system, then /usr/local is supposed to be off limits. Installing to /usr is preferred, but the appropriate installation location for non-standard packages that can't be installed in /usr is /opt. This guideline applies to distro maintainers and upstream providers, not the end user.
Anybody packaging Trinity for self-use can install to /usr/local. The moment those packages are provided for others then /usr/local is inappropriate.
Anyone building the Trinity packages for personal use only can install to /usr/local if desired. Start packaging for other users and /usr/local becomes inappropriate.
For myself I don't install any upstream provided packages in /usr/local because I use /usr/local for things I create on my own. I keep /usr/local on a separate partition, which keeps that file system separate from everything else. That is, /usr/local is mine and I do what I want there.
I build Trinity to install in /opt/trinity because I build my packages usable by other users with the same distro. If the upstream distro I use did not include KDE4 then I would build to install to /usr. If I was creating my own custom distro I would build to install in /usr because I would not include KDE4.
Darrell
On 02/23/2012 10:23 AM, Darrell Anderson wrote:
trinity is not software locally installed by the local
system admin?
Right now it is - but very soon it will be installed from mirrors, via the package manager; users are expecting /usr/local to be stuff installed by them not the package manager
/usr/local is for the user. What users want to do with their /usr/local is for them to decide.
Upstream maintainers are not supposed to install anything in /usr/local. When software is provided by upstream providers as part of a distribution's package system, then /usr/local is supposed to be off limits. Installing to /usr is preferred, but the appropriate installation location for non-standard packages that can't be installed in /usr is /opt. This guideline applies to distro maintainers and upstream providers, not the end user.
Anybody packaging Trinity for self-use can install to /usr/local. The moment those packages are provided for others then /usr/local is inappropriate.
Anyone building the Trinity packages for personal use only can install to /usr/local if desired. Start packaging for other users and /usr/local becomes inappropriate.
This is just until all the conflicts are hammered out? After that all of this is mute point.
Again I use /usr/local so that I can move it to /usr very easily, ever try cp -var /opt/tde into /usr?
rsync -var or cp -var /usr/local /usr works every time. Everthing goes where it should.
For myself I don't install any upstream provided packages in /usr/local because I use /usr/local for things I create on my own. I keep /usr/local on a separate partition, which keeps that file system separate from everything else. That is, /usr/local is mine and I do what I want there.
I have partitions that I mount to /usr/local.... working, wip, broken a little, broken somewhat and very broken.
I also mount 3.5.10 when I need to and mount 3.5.12 when I working on it.
If say tde is broken I can just not mount it for the user till I get it fixed then remount it.
Also if I need to try something out I can mount the "in test" partition and if it don't work just mount the partition that works to /usr/local.
I build Trinity to install in /opt/trinity because I build my packages usable by other users with the same distro. If the upstream distro I use did not include KDE4 then I would build to install to /usr. If I was creating my own custom distro I would build to install in /usr because I would not include KDE4.
I do both....upstream distro, users with KDE4 and users without KDE4 and tde installed. Then the only difference is /usr/local to /usr is just a cp away.
Sigh.
What it comes down to is that there are three things that influence the choice of where to install Trinity, and two are very dependent on the policies espoused by a given distro:
-Is Trinity being installed through a package manager, or by hand? If the latter, all bets are off and it could literally end up anywhere.
-Does this distro normally install KDE4 to a segregated location (/opt/kde4, /usr/kde/4, or whatever), or root it directly in /usr, which results in its applications landing in /usr/bin, where they can't easily be filtered from the PATH to avoid conflicts?
-What is this distro's package installation policy? Does it adhere to the FHS slavishly, consider it useful but non-binding, or ignore it? Are things normally sent to /usr, to /opt, or somewhere else? Is there a specific reason to violate the standard policy in Trinity's case?
If I'm not mistaken, there are people from multiple distros (not just Arch people) now embroiled in this argument, and I don't think it's possible for us all to ever agree on a "best" installation location. Let each packager make the decision on the basis of what's best for their distro; multiple packagers working on the same distro need to hash it out between themselves (ideally without drawing people from other distros into the mess); non-packagers can install to /rahrahtrinity if they want to and are willing to deal with the consequences.
On Wed, 22 Feb 2012 17:19:15 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
For the rest of the community -- Where are you putting tde?
/usr/tde/[version] , with the intent of paralleling the standard Gentoo KDE3 install location of /usr/kde/[version] . /opt is out of the question for us--distro policy is to use it only for precompiled binary blobs, which Trinity is not.
On 22 February 2012 18:19, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Archers, All,
Currently, Arch installs trinity to /opt/trinity. Personally, I would like to move the default install to /opt/tde. Two reasons: (1) most important -- less typing; (2) the tradition of the install being in /opt/kde, why not standardize around /opt/tde?
Sure - if it bothers you that much :-)
For the rest of the community -- Where are you putting tde? It would just make sense to set a community-wide standard. Yes, I know that the location is irrelevant and can be obtained by the standard environment files, but we recently had a rebuild of 3.5.12 that moved from /opt/kde to /opt/kde3. That's fine, but depending upon the repo you hit to pull files from, your system would break due to install location differences in the various packages.
I don't have any hard feelings either way for any single location, but if it is all the same, then if possible, I would like to see a standard that all packagers could reference. Of course you don't have to use it, but if there is a standard install, the balance of builds will migrate to it over time.
What says the team?
/opt/trinity /opt/tde /opt/tde_ver (ver being a 2 or 3-digit version: eg. 13 or 313) /opt/other_suggestions?
Personally for me, /opt/tde works :)
(/opt/trinity is probably my fault on arch anyway :)
from filesystem heirarchy standard
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate / opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.
I want to avoid anything in /usr/ OR /usr/local. esepcailly because this will lead to overwriting of custom built kde4 apps ( which I have ).
I do not want to use /opt/tde_ver/ - this is why we have package managers, so we don't need to maintain separate folders for each version. let pacman handle the versions :-)
/opt/tde /opt/trinity either one is fine.
Calvin
-
Baho Utot -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
Jay -
Robert Xu -
Timothy Pearson