On 02/22/2012 07:05 PM, Robert Xu wrote: proof great minds think alike: 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? -- David C. Rankin, J.D.,P.E.

On 02/22/2012 08:01 PM, Jay wrote: ...depends on how old your fingers are... :) -- David C. Rankin, J.D.,P.E.

On 23 February 2012 08:41, Baho Utot <baho-utot(a)columbus.rr.com> wrote: Again: 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

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 Just because it is not installed by default doesn't mean it shouldn't operate as a normal package. 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. I have offered many a time to have you join up and you consistently refuse. 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

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. 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/ exactly. 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. Certainly not with that attitude. Calvin Morrison

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. wat. Using TDE as my "prime time" desktop since 2010, Calvin

On 23 February 2012 10:45, Baho Utot <baho-utot(a)columbus.rr.com> wrote: 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

On 02/23/2012 10:47 AM, Calvin Morrison wrote: You skirt the issue We are not talking arch here Would you use tde in a corperate environment?

On 02/23/2012 11:35 AM, Calvin Morrison wrote: 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.

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

Of course. I was referring to usability/functionality/stability problems in FOSS, and was not attemting to solve vendor lock-in issues. Fixed. Coincidentally I was working on that bug earlier today and just pushed the patches in a few minutes ago. Tim

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

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

/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

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.