Re: Misleading directory names
On Tue, September 28, 2010 4:31 pm, Antonio Huete Jimenez wrote: > Justin, > > How would anyone be using amd64 directory for 2.0 if we didn't have it > back then? Well, no, but if you think about it for a bit you'll realize it's an example to show how long support can be needed for some people, not an history of when packages for amd64 were out. Nature took its course and we ended up having to move older pkgsrc binaries anyway because the archive was getting too big for people to mirror easily.
Re: Misleading directory names
Justin, How would anyone be using amd64 directory for 2.0 if we didn't have it back then? Anyways this is not a big issue in my opinion. amd64 is a directory and x86_64 a symbolic link to it. It only contains packages for 2.6 and 2.7 and by those releases our 64-bit arch. name is x86_64 so I see no point in having both amd64 and x86_64. I would say wipe out x86_64 symbolic link and rename amd64 directory to x86_64 just for consistency. People navigating with a browser the package hierachy is not as unusual as we might think. For example, when you are looking for a specific package to know its URL so pkg_add works properly fetching all the other dependencies, or when you're looking for the URL to set on pkgin's configuration file. Cheers, Antonio Huete > I appreciate what you're saying about having things be clear to users, but > this is the alternative to something that would be more confusing. > 'amd64' was hardcoded into a number of package tools, including early > versions of pkg_radd. The choice is either leave it untidy with a note > about the reason for the directory, or break functionality for older > machines. > > Someone was still running a number of 2.0 machines in an environment that > couldn't be easily upgraded, last I asked about this, so untidy is a > better choice, in this case. > > The long-term answer that I would prefer is to not have people need to > navigate a package hierarchy at all, and instead have the appropriate > software selected automatically. We're closer to that with the pkg_radd >
Re: Misleading directory names
On Tue, September 28, 2010 6:58 am, PrzemysÅaw PaweÅczyk wrote: > Doesn't it seem to you like being a bit untidy? And, btw, for how long > "the legacy" will be going on...? With so much changes between 2.6.3 > and 2.8.0? Do you really think/know that "the legacy" systems will be > kept running yet after new release (which one)? > > Manpower shortages define status quo, no doubt about it, as > pkg_radd/pkg_search are still unchanged with amd64 links. I appreciate what you're saying about having things be clear to users, but this is the alternative to something that would be more confusing. 'amd64' was hardcoded into a number of package tools, including early versions of pkg_radd. The choice is either leave it untidy with a note about the reason for the directory, or break functionality for older machines. Someone was still running a number of 2.0 machines in an environment that couldn't be easily upgraded, last I asked about this, so untidy is a better choice, in this case. The long-term answer that I would prefer is to not have people need to navigate a package hierarchy at all, and instead have the appropriate software selected automatically. We're closer to that with the pkg_radd tool.
Re: Misleading directory names
Przemys?aw Pawe?czyk wrote: > On Tue, 28 Sep 2010 12:14:52 +0200 > Matthias Schmidt wrote: > > (...) >> > 2. Would you put the information about legacy into every nook and >> > cranny of DFBSD documentation? Nope. What's the purpose then to >> > litter DFBSD and mirror servers with the Doublespeak? ;-) Let >> > bygones be bygones. ;-) >> >> There might be older installations out in the wild whose tools depend >> on the amd64/ link, e.g. pkg_radd/pkg_search. >> >> So what's the issue with having two entries with the same target in >> the directory of a mirror server? Even if there is a README which >> explains that amd64 == x86_64. *scratcheshishead* > > Doesn't it seem to you like being a bit untidy? And, btw, for how long > "the legacy" will be going on...? With so much changes between 2.6.3 > and 2.8.0? Do you really think/know that "the legacy" systems will be > kept running yet after new release (which one)? > > Manpower shortages define status quo, no doubt about it, as > pkg_radd/pkg_search are still unchanged with amd64 links. > > I tell you sincere, I made "research", my posts may testify, how > far the system is "mature" - of course on my terms, not DFBSD > developers'. And I didn't buy the "production ready" hype. > > Regards > > -- > Przemys?aw Pawe?czyk (P2O2) [pron. Pshemislav Paveltchick] > http://pp.blast.pl, pp...@o2.pl O.k. I understand you dont like our documentation.. We welcome Ideas and Suggestions about such things. Dfly is new? not really.. for the record.. when I worked at a small isp in atlanta, ga we had a box that had been running for several years without issue. we upgraded software on it.. we did a lot of stuff on it.. however it was never rebooted. legacy systems in the real world exist. We will continue to support those legacy systems. We have done so in many ways including abi support for old binaries. Now to the issue, the real issue I have so far avoided this discussion, for fear that I would say something I shouldnt. Its this simple... sometimes I wish we had the old installer back... the one where you had to manually set everything up.. and cpdup the filesystem over by hand. This pretty much seperated out the poeple who went to install something and complain about every issue they might find with it. I understand that a operating system without users is pretty useless. However berating the developers of that o.s. is pretty useless as well. There will be a day if you continue using Dfly that you will need answers, and the only onees who can provide them are the people that have been insulted in your messages. So tone it down, ask for help, point out the issues you find in a friendly manner and you will find them corrected very quickly. Continue the path that these messages have been headed down, and you will have guys arguing against changes that we should make. Just because you suggested them. Sincerely, Robert Garrett
Re: Misleading directory names
On Tue, 28 Sep 2010 11:59:02 +0100 Alex Hornung wrote: > On 28/09/10 11:44, Przemysław Pawełczyk wrote: > > A real example - I installed DFBSD and I wanted to have some > > applications too. I went to the page: > > http://www.dragonflybsd.org/docs/howtos/HowToPkgsrc/#index4h2 > > > > There is setenv PKG_PATH .../i386/... defining the path to packages' > > database. > > > For whatever it's worth, if you just mentioned the actual problem > first instead of criticizing that there are two different directories > for the same architecture on a mirror, your criticism/comments would > be very useful from the start. > > I much appreciate that you let us know which issues you find but > raising the actual issue instead of talking around it and only > getting to it 3 mails later isn't as useful as it could be. > > Regards, > Alex That's the same problem Round Robin - whether to keep the info short as everybody else is quick-witted and thus any further discription would be unwelcome (offending), or put it in broader context from the start. I have chosen a "middle road" - first short message, then description if it would be necessary. Anyway, I will think over your remarks. Thanks. Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpkXorzuwH8q.pgp Description: PGP signature
Re: Misleading directory names
On 28/09/10 11:44, Przemysław Pawełczyk wrote: > A real example - I installed DFBSD and I wanted to have some > applications too. I went to the page: > http://www.dragonflybsd.org/docs/howtos/HowToPkgsrc/#index4h2 > > There is setenv PKG_PATH .../i386/... defining the path to packages' > database. > For whatever it's worth, if you just mentioned the actual problem first instead of criticizing that there are two different directories for the same architecture on a mirror, your criticism/comments would be very useful from the start. I much appreciate that you let us know which issues you find but raising the actual issue instead of talking around it and only getting to it 3 mails later isn't as useful as it could be. Regards, Alex
Re: Misleading directory names
On Tue, 28 Sep 2010 12:14:52 +0200 Matthias Schmidt wrote: (...) > > 2. Would you put the information about legacy into every nook and > > cranny of DFBSD documentation? Nope. What's the purpose then to > > litter DFBSD and mirror servers with the Doublespeak? ;-) Let > > bygones be bygones. ;-) > > There might be older installations out in the wild whose tools depend > on the amd64/ link, e.g. pkg_radd/pkg_search. > > So what's the issue with having two entries with the same target in > the directory of a mirror server? Even if there is a README which > explains that amd64 == x86_64. *scratcheshishead* Doesn't it seem to you like being a bit untidy? And, btw, for how long "the legacy" will be going on...? With so much changes between 2.6.3 and 2.8.0? Do you really think/know that "the legacy" systems will be kept running yet after new release (which one)? Manpower shortages define status quo, no doubt about it, as pkg_radd/pkg_search are still unchanged with amd64 links. I tell you sincere, I made "research", my posts may testify, how far the system is "mature" - of course on my terms, not DFBSD developers'. And I didn't buy the "production ready" hype. Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpzjpDabtbnn.pgp Description: PGP signature
Re: Misleading directory names
On Tue, 28 Sep 2010 12:03:42 +0200 Antonio Huete Jimenez wrote: > Hi Prezemylaw, > > I know no OS which is finished. There's always things to do ;) > > Besides that I think the amd64 symlink could be removed as there's no > 2.6/2.7 release with arch. name, but it isn't either a big deal. Hi Antonio, Yes, I exaggerated a bit but with purpose. Let me explain why. So what is "a big deal" depends on the place you are - outside the project as a newly DFBSD "worshipper" ;-) or inside the project being a seasoned user. A real example - I installed DFBSD and I wanted to have some applications too. I went to the page: http://www.dragonflybsd.org/docs/howtos/HowToPkgsrc/#index4h2 There is setenv PKG_PATH .../i386/... defining the path to packages' database. OMG! I installed 64 bit system and there is only i386 address! What the heck? And then I started to search the website. What to put there instead of i386 - amd64 or x86_64, where is the f*** information 'bout it, etc. A few minutes of frantic activities and either you get it or you are lost. I know that I should go there or should try to substitute the "i386" in my brower with well, with what - x64, amd64, x86_64, 64bit? There are such things like ergonomics and "predictable search time" (sensable search time). You have to take them into consideration creating documentation to any projects if you want to attract prospective users. From Wikipedia: Ergonomics is the science of designing user interaction with equipment and workplaces to ***fit the user***. If I am not able to find such a trifle what to say 'bout something more complex? I have been leaving projects or websites very frequently not having obtained needed information in sensible time. Quick access to data is an __iron tenet__ of Internet surfing or good propaganda (aka Public Relation). Not to say that any ambiguities within documentation is manifestation of (mind) sloppiness. Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgprzzl8q1NNy.pgp Description: PGP signature
Re: Misleading directory names
* Przemys??aw Pawe??czyk wrote: > > 1. Having DFBSD so young and calling former releases "a legacy" is kinda > hoity-toity. ;-) AFAIK the DFBSD is not __finished__ yet so former > versions were at best development releases. At least a lot of people have DragonFly running on a lot of machines in production environments. All backend servers in our working group are based on DF. > 2. Would you put the information about legacy into every nook and > cranny of DFBSD documentation? Nope. What's the purpose then to litter > DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be > bygones. ;-) There might be older installations out in the wild whose tools depend on the amd64/ link, e.g. pkg_radd/pkg_search. So what's the issue with having two entries with the same target in the directory of a mirror server? Even if there is a README which explains that amd64 == x86_64. *scratcheshishead* Matthias
Re: Misleading directory names
Hi Prezemylaw, I know no OS which is finished. There's always things to do ;) Besides that I think the amd64 symlink could be removed as there's no 2.6/2.7 release with arch. name, but it isn't either a big deal. Cheers, Antonio Huete 2010/9/28 Przemysław Pawełczyk : > On Tue, 28 Sep 2010 03:30:28 -0600 > "Samuel J. Greear" wrote: > >> 2010/9/28 Przemysław Pawełczyk : >> > Hi, >> > >> > Listing from http://avalon.dragonflybsd.org/packages/ >> > >> > Name Last modified Size Description >> > Parent Directory - >> > README 18-May-2010 02:45 1.3K >> > amd64/ 24-Aug-2010 23:56 - >> > i386/ 27-Sep-2010 20:59 - >> > x86_64/ 24-Aug-2010 23:56 - >> > >> > Why there are two __identical__ directories under __two__ different >> > names which stand for the same contents? >> > >> > Excerpt from README: >> > >> > What's here >> > >> > >> > The i386 directory contains packages built on 32-bit DragonFly >> > systems. The amd64/x86_64 directores contains packages built on >> > 64-bit DragonFly systems. >> > >> > (amd64 and x86_64 are the same thing here) >> > ^^^ >> > >> > Why the mess? >> > >> > Regards >> > >> > -- >> > Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] >> > http://pp.blast.pl, pp...@o2.pl >> > >> >> Our x86_64 branch used to be called amd64, it's just legacy. >> >> Sam > > Hi, > > 1. Having DFBSD so young and calling former releases "a legacy" is kinda > hoity-toity. ;-) AFAIK the DFBSD is not __finished__ yet so former > versions were at best development releases. > > 2. Would you put the information about legacy into every nook and > cranny of DFBSD documentation? Nope. What's the purpose then to litter > DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be > bygones. ;-) > > Regards > > -- > Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] > http://pp.blast.pl, pp...@o2.pl >
Re: Misleading directory names
On Tue, 28 Sep 2010 03:30:28 -0600 "Samuel J. Greear" wrote: > 2010/9/28 Przemysław Pawełczyk : > > Hi, > > > > Listing from http://avalon.dragonflybsd.org/packages/ > > > > Name Last modified Size Description > > Parent Directory - > > README 18-May-2010 02:45 1.3K > > amd64/ 24-Aug-2010 23:56 - > > i386/ 27-Sep-2010 20:59 - > > x86_64/ 24-Aug-2010 23:56 - > > > > Why there are two __identical__ directories under __two__ different > > names which stand for the same contents? > > > > Excerpt from README: > > > > What's here > > > > > > The i386 directory contains packages built on 32-bit DragonFly > > systems. The amd64/x86_64 directores contains packages built on > > 64-bit DragonFly systems. > > > > (amd64 and x86_64 are the same thing here) > > ^^^ > > > > Why the mess? > > > > Regards > > > > -- > > Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] > > http://pp.blast.pl, pp...@o2.pl > > > > Our x86_64 branch used to be called amd64, it's just legacy. > > Sam Hi, 1. Having DFBSD so young and calling former releases "a legacy" is kinda hoity-toity. ;-) AFAIK the DFBSD is not __finished__ yet so former versions were at best development releases. 2. Would you put the information about legacy into every nook and cranny of DFBSD documentation? Nope. What's the purpose then to litter DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be bygones. ;-) Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpEgN9F9dky5.pgp Description: PGP signature
Re: Misleading directory names
2010/9/28 Przemysław Pawełczyk : > Hi, > > Listing from http://avalon.dragonflybsd.org/packages/ > > Name Last modified Size Description > Parent Directory - > README 18-May-2010 02:45 1.3K > amd64/ 24-Aug-2010 23:56 - > i386/ 27-Sep-2010 20:59 - > x86_64/ 24-Aug-2010 23:56 - > > Why there are two __identical__ directories under __two__ different > names which stand for the same contents? > > Excerpt from README: > > What's here > > > The i386 directory contains packages built on 32-bit DragonFly > systems. The amd64/x86_64 directores contains packages built on 64-bit > DragonFly systems. > > (amd64 and x86_64 are the same thing here) > ^^^ > > Why the mess? > > Regards > > -- > Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] > http://pp.blast.pl, pp...@o2.pl > Our x86_64 branch used to be called amd64, it's just legacy. Sam
Misleading directory names
Hi, Listing from http://avalon.dragonflybsd.org/packages/ Name Last modified Size Description Parent Directory - README 18-May-2010 02:45 1.3K amd64/ 24-Aug-2010 23:56- i386/27-Sep-2010 20:59- x86_64/ 24-Aug-2010 23:56- Why there are two __identical__ directories under __two__ different names which stand for the same contents? Excerpt from README: What's here The i386 directory contains packages built on 32-bit DragonFly systems. The amd64/x86_64 directores contains packages built on 64-bit DragonFly systems. (amd64 and x86_64 are the same thing here) ^^^ Why the mess? Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpNqSIYjAEiM.pgp Description: PGP signature
