Re: namespace conflict != package Conflict?
On Wed, 15 Jun 2005, Anthony Towns wrote: Steve Greenland wrote: On 12-Jun-05, 02:27 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: You need to convince either git or GNU Interactive Tools to change its name upstream then. Since git is the newcomer and its name is already taken (by a GNU project no less!) perhaps you could start there. The existence of the GNU Interactive Tools was noticed when Linus picked the name 'git'. The discussion then noted that this previous use of the name was more-or-less dead upstream, and not widely used. The upstream name isn't going to change. There are probably already more users of GIT-the-VCS than GIT-the-tools. So if you rename git for Debian, we are very likely going to to be incompatible. Uh, so why hasn't the option of renaming (or just dropping) GNU Interactive Tools been discussed? Policy might require us to not have two packages installing different functionality under the same command name, but it doesn't require us to adopt "first come, first served". It was mentioned (on the Mentors list anyways) but didn't seem to garner much support as a first-pass solution... I chaulk it up to the collective just knowing that "first come, first served" is about a fair a rule-of-thumb as we can have in this situation. GNU Interactive Tools hasn't seen an upstream update at all since 2001, and looking at the diffs since .18, doesn't seem to have had any significant changes since 1999. The Debian updates seem mostly to be updating the build system, rather than user-visible changes. GIT is flexible, not too bloated, not lacking anything significant or obvious, and has been that way for awhile (the command line and tools haven't changed, why should GIT)... iow, it is mature - why should that be held against it? Popcon says: #nameinst vote old recent no-files cogito7010 159 0 git 95196610 0 which aiui means that 10 of 11 cogito installers use it regularly, while 19 of 85 git installers do; the "59 recent" presumably screws the stats up a bit much. See what happens when you upload your packages? Another thing which is likely to mess up popcon based comparisons is the widely different usage patterns. GIT is a sh TUI, git-for-cogito is essentially a function call; I typically fire up GIT soon after logging in and it is useful for days-to-weeks on a single "use", by its nature git-for-cogito will see many more instances of "use" even if it is only being useful for a day. [then again, I may completely misunderstand what popcon generates ] Personally, I think the best solution is to leave the filesystem level error (two /usr/bin/git's) intact in the uninstalled Debian (the .debs) and present the sysadmin with the most reasonable options for resolving it when they select the affected packages. Ya, I know what that would involve to do "poperly", so I'm not suggesting it be done right now or just for this instance of the problem. Anyways, I'm confident the collective DD's will eventually do the right thing. In the short term, I'm glad the precedent which would be set by discarding a name/path with a long and useful history is seen as worthy of argument. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
On Thu August 10 2006 10:16, martin f krafft wrote: > also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2006.08.10.1647 +0100]: > > How about allowing conffiles to list files that are generated at > > install time and are not included in the deb? > > You can, but then you run up against policy. You are not allowed to > touch a conffile with a script. Is there anything prohibiting an "update-package.list" command? Would updating /var/lib/dpkg/info/*.list files without touching the appropriate Installed-Size: field be OK? Is there any way to get a handle on how much more CPU time and HDD space would be used if all packages updated their meta-info at install time? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
On Thu August 10 2006 12:40, martin f krafft wrote: > also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1925 +0100]: > > Would updating /var/lib/dpkg/info/*.list files without touching the > > appropriate Installed-Size: field be OK? > > Definitely not. /var/lib/dpkg is the domain of dpkg. Do not go > there. You must not even assume that /var/lib/dpkg/info/*.list is > the list of installed filed. Such a utility would need to be shipped with dpkg, a 3rd party or random DD implementing it would be silly for anything but local consumption. Is that the only problem? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
On Thu August 10 2006 13:13, martin f krafft wrote: > also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1959 +0100]: > > Such a utility would need to be shipped with dpkg, a 3rd party or > > random DD implementing it would be silly for anything but local > > consumption. > > > > Is that the only problem? > > If dpkg knew how to track files it did not directly install, of > course it would be of benefit. The question is how to let it know > which files are meant by this. I suppose DEBIAN/conffiles-(files > installed to /etc by the package) would work, but I'd be careful > about touching the "conffile" concept. Maybe DEBIAN/dynfiles -- > since after all it (sh|w)ould be used for things like logfiles as > well. And it should be able to just take a directory, like > /var/lib/dpkg, assuming that everything underneath that directory > would be created by one package, dpkg in this case. I would expect usefulness with most generated files (all, if one thinks that every file resulting from a pkg install should be "dpkg -S"-able). It may also be useful to create local virtual packages for stuff like "papersize" if there is no good package to append them to. An "update-package" command, run at install time by the maintainer's scripts right after file generation succeeds, would head off potential problems with synchronization that are outside of the Maintainer's control (e.g., DEBIAN/dynfiles containing incorrectly generated paths) and would be simpler to implement, specifically, dynfiles vs. "update-package": an infrastructure which operates at package build and install time, requiring packages and all helpers to be re-engineered[1] to make use of the feature vs. a command which knows how to append a file to a package and can be added to any package's scripts with a line or two of minor code, only depends on dpkg's external stability to continue to work, and whose behaviour could be controlled from a single point[2] Adding a directory appears to be something which could be useful (even if only as a shorthand notation[3]), but I don't think it could be done without touching dpkg internals and a big chunk of the tools (recognizing that a directories contents are owned by a pkg is new). - Bruce [1] "re-engineered"... maybe a bit dramatic and overstated, but unless there is a way to pick the generated paths out of the existing maintainer scripts the conversion would require re-thinking and re-doing existing work, afaict [2] `single point control'... seems to be an important characteristic given the Python transition's recent problems with the various tools being out of sync wrt an evolving policy [3] "if only as..." if the typical .list file is less than the size of a typical disk block then there could be an additional processing overhead for no gain in the typical case, that would suck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
On Thu August 10 2006 15:10, martin f krafft wrote: > also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.2124 +0100]: > > An "update-package" command, run at install time by the > > maintainer's scripts right after file generation succeeds, would > > head off potential problems with synchronization that are outside > > of the Maintainer's control (e.g., DEBIAN/dynfiles containing > > incorrectly generated paths) > > That's a bug then. I'd much rather prefer maintainer control than > some script magic. How would the script determine which files were > added anyway? No point setting oneself up for bugs if it is not necessary. The script wouldn't determine anything, it would simply append paths to the package's list of paths. The Maintainer would need to call the script "right after file generation succeeds", or perhaps with a list of files just generated, or as part of an install if packageless files are known to exist. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
On Thu August 10 2006 16:20, martin f krafft wrote: > also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.2237 +0100]: > > No point setting oneself up for bugs if it is not necessary. > > > > The script wouldn't determine anything, it would simply append > > paths to the package's list of paths. The Maintainer would need to > > call the script "right after file generation succeeds", or perhaps > > with a list of files just generated, or as part of an install if > > packageless files are known to exist. > > Ah, now I understand. Yeah, sounds like a good idea. After all, > a file may or may not be created, something not known during build > time... > > So when can we expect patches from you? ;) Seems like the kind of thing which should be done by a DD or [EMAIL PROTECTED] (especially since it relies on dpkg's behaviour and mucks with their DB). I will be so bold as to suggest... Synopsis: update-package [options] update-package [options] --add-files= update-package [options] --remove-files= update-package [options] --size= update-package [options] --field=:: Commands: --*-files modifies the indicated package's list of files --size changes or modifies a package's Installed-Size: field --field changes the value of an arbitrary field in a package's DB entry "files" and "size" accommodate the desire to include generated or packageless files and their size (if knowable) in the dpkg DB. "field" can be used by an admin to override a package's meta-information so it better reflects local changes in those cases where building a new package is overkill. e.g.: a local Maintainer: for a pkg with config changes only, new Depends: and/or no need for an equivs package to hack around a temporary problem or situation. Potentially a very nasty command. [what can I say, it is not that unusual for me to "editor /var/lib/dpkg/status" to work around a packaging problem, or dpkg/info/.list then dpkg-repack and install somewhere else... but maybe I'm "evil" or enshrining the ability in a utility would send the wrong message... perhaps another reason for a DD or [EMAIL PROTECTED] to provide the functionality ] Options: - the usual useful stuff (help, version, verbosity, logging) - maybe an admin controlled "off" switch, just in case having a local DB which differs from the packaged one is a problem (implies a config file somewhere) - automatic Installed-Size: updating, not always useful or accurate, maybe best left as a invocation only option because only the Maintainer knows for sure Files: /sbin/update-package /usr/share/man/man8/update-package /etc/update-package and/or $HOME/.update-package ..., write some more if necessary to clarify something, and be an early adopter/test-dummy though. :-) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
On Fri August 11 2006 04:51, Ian Jackson wrote:
> Bruce Sass writes ("Re: Silly Packaging Problem"):
> > "files" and "size" accommodate the desire to include generated or
> > packageless files and their size (if knowable) in the dpkg DB.
>
> This is a bad idea. dpkg maintains these lists of files not
> primarily for the purpose of dpkg -S, but rather for making the
> package management operations (install, upgrade, remove, etc.) work
> properly.
>
> If you start editing these files (even with the relevant lock held
> and with regard to the package status), dpkg will behave differently
> afterwards: it will think the file in question was shipped in the
> currently installed package's .deb.
iow Hacking the DB may work while the system is static but not in the
middle of (say) installing 2+ pkgs.
> This is almost certainly not what you want. A good general principle
> is to practice ownership: dpkg should remove and update things it has
> installed; maintainer scripts and other programs should remove and
> update things they created.
It looks to be what is wanted, eventually anyways. Queueing the
update-package commands and processing them after dpkg finishes could
work?
I agree with that general principle, in this case dpkg already owns the
data (list of files in the package and Installed-Size). ;-)
[insert "dpkg DB->.deb" vs. "dpkg DB->system" argument]
[insert ".deb->created files" vs. ".deb + created" argument]
> If the objective is to make dpkg -S more useful (a worthy goal) then
> you need a separate list for each package, of files which should be
> reported in -S but which dpkg should otherwise ignore.
It looks like ensure_packagefiles_available() in filesdb.c would be the
place to do this (essentially duplicating most of the action in lines
115-172 with a different filelistfile, maybe only if doing -L or -S?),
afaict, but my C's pretty old and rusty.
- Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
On Sat August 12 2006 09:34, Matthias Klose wrote: First time I've seen the design goals laid out like this. Thanks, and sorry if this is out of place. > No, not the whole design goal. Although the document is titled > "developer's view", the other goals should be mentioned as well. > These are meant to work around processes in debian which are > currently suboptimal, but unlikely to change. > > - The need to support more than one version of a python runtime or >to support different implementations was seen. It takes a while >until applications support a new version. What is needed now is a way to prevent all but the "default" modules and those selected by the admin from being built for all installed runtimes so Debian can re-step forward and properly support multiple runtimes. The new policies all-or-nothing attitude wrt modules is too much. It effectively forces one Python only and unnecessarily discourages Python hackers and developers because the cost of carrying all modules for all installed versions, instead of just those modules needed for the work being done in the different versions, can be quite high for someone with a comprehensive installation of even one Python version. > - The old schema of using pythonX.Y-foo packages let's land packages >in the NEW queue, when support for another python runtime is added >to the package. That certainly is a process, which could be >addressed by FTP master (do not process a pythonX.Y+1-foo package >manually, if pythonX.Y-foo is already in the archive). If pythonX.Y+1-foo has a "-1" or "-0.x" Debian version then it is a NEW package... >Having pythonX.Y-foo mentioned in the control file would disallow >binary NMU's in situations where a python runtime is dropped or >added (the control needs to be regenerated). A solution would be >to define an own target to regenerate the control file, which is >not called during the normal package build. Such source package >would not be binNMUable, but could be the target of automated >uploads. ...as are all packages built against a new runtime (see next paragraph), and if an X.Y runtime is dropped so are any X.Y-foo packages. So, what is the objective of this design goal? Pushing untested packages into the archive appears to be the result. Python routinely spits out warnings about code breaking changes happenning at the minor version level, surely that requires better handling than blindly binNMUing packages (what else can mass binNMU's be?)... the package's metainfo looks good, but nobody familiar with the code has actually tried the combination (build, intalled, and at least some testing) to see how it works, with any arch? That is un-Debian-like, even for unstable, and as a 10+ year Debian user I think I am within my rights to make such a judgement. > - Putting extension modules for more than one python version into >a package eases transition of these packages to the testing >distribution, provided that the package supports to default python >version in testing and the default python version in unstable. >The schema used before with python-foo depending on >python-foo required an extra upload of every package >containing an extension, adding new dependencies on new shared >libraries in unstable, but not yet in testing. All packages having >a python (<< X.Y) dependency had to be moved to testing at once. This needed to be fixed, but more time should have been taken in the planning because the entirety of the solution is even more suboptimal than the previous (incomplete) policy, imo. The thing that seems really telling in all this is that team maintenance promises to increase the quality of packages, yet Debian's Python team is explicitly using it to potentially decrease quality with mass binNMUs to speed up transitions to new runtime environments. I really hope someone shows how I've just made a fool of myself but I don't have a lot of confidence that will happen because speed and quality are usually a trade-off. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"only declare Provides when"
On Mon August 14 2006 00:03, Steve Langasek wrote: > ... my premise > that pure python modules should only declare Provides when something > exists in the archive which actually *needs* them... What of stuff which will never be in the archive? ["ask for it" is an obvious answer, so...] Any thoughts on handling developers when Debian's Maintainer disagrees as to whether their package *needs* to declare a Provides or is slow providing it? I'm thinking of scenarios like: - packaging stuff for Debian Package can't be tested until the Provides appears and there may be more than one way to do the new packaging, so: build a local package to Provide, wait and NMU, or bug report and wait. - in-house/3rd-party packages In addition to needing a Provides Debian doesn't there may be need to package in a non-Debian manner (leading to the second question), so: local packages, or file bug report - non-free non-redistributable Should be no different than in-house/3rd, but some Maintainers want nothing to do with non-free and may balk or delay at Providing for `non-free crap' that's not even free enough for non-free. [only brought up as a potential bad press/flamewar alert, should not be taken as crying 'cause non-free has a harder time of it :-] I have a feeling that Providing local X.Y-foo's for all installed X.Y's could work without hurt under that premise. I'm not sure how to communicate X.Y+foo="X.Y-foo" to other packages, or if it is necessary to do that (worst case: install of foo fails and user see that X.Y is needed?) Local virtual Provides could be (uhm) interesting. Is there any way around these problems which doesn't require on-the-fly package creation or dpkg DB editing, or maybe they are not really problems? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
On Tue August 22 2006 13:04, Josselin Mouette wrote: > Given that downloads like Debian ISOs are already putting a heavy > bandwidth load on the servers and that they are already shared among > many servers, I don't think it is a good idea to encourage users to > load several servers at once with one download. We should instead > push bittorrent as the main distribution media for ISOs. or as the main distribution media. This is user supported software, why not user distributed also. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
On Wed August 23 2006 05:30, Hendrik Sattler wrote: > Am Mittwoch 23 August 2006 12:41 schrieb Josselin Mouette: > > Le mercredi 23 août 2006 à 11:30 +0200, Christian Perrier a écrit : > > > I have a few doubts about the knowledge of the average user for > > > Bittorrent. For sure, having BitTorrent helps reducing the load > > > because all users that have some know-how with it will use > > > it...but making it the main distribution mode...ahem.I think > > > that most of the users will stick to ISO images downloads. > > > > When a nice bittorrent frontend is installed, the user will only > > have to click on the link to start the download. This is true for > > Windows and Linux. > > If, not when. There is no bittorrent client in any Suggests: or > Recommends: line of any of the browsers in Debian. And I guess that > most system do not have one intalled. > However, http and ftp will always work as that is the same method as > the one used to access the download page. A browser Suggests: or Recommends: is not really needed as most bittorrent clients appear to be standalone programs, it is also a little silly for browsers to suggest or recommend clients for every mime-type out there. "http and ftp will always work" is a really good point... someone mentioned `corporate filtering,' I think bandwidth limiting by ISPs would be a bigger problem. Shouldn't be a deal killer though, just don't use bittorrent as the only method. Best, imo, would be a new torrent-like protocol and some serious PR to minimize the possibility of it being seen and used as just another p2p network the RIAA (whoever) doesn't like. - Bruce
Re: Debian ISOs
On Wed August 23 2006 12:32, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] writes: > >When a nice bittorrent frontend is installed, the user will only > > have to click on the link to start the download. This is true for > > Windows and Linux. > > You left out the reconfigure the firewall(s) step. Not only is this > non-trivial, the user may not have the ability to do so. This is a bit of a red herring. Torrents work without re-configuring firewalls, they just don't work as well. There appears to be two reasons for that (all of this is, "afaict", and I've only looked at it superficially so far): The desire to spread the server load over many peers and foil "leeches" has resulted in a policy where `the download rate is proportional to the upload rate.' With an unconfigured firewall the client can only upload to clients it is downloading from, it is the resulting limited upload rate which chokes the download rate. Since the policy is set by the tracker, and Debian would need to manage its own tracker[1], this problem should be managable without too many hoops. Another reason for non-trivial reconfiguration is because clients can have braindead out-of-the box configurations. e.g., last time I looked at bittornado it was setup to randomly use any of 50,000 ports[2]. The user ends up needing to configure both the firewall and client to realize the full potential. So, if the problem above is managable, this one would be a non-issue. On the other hand, if it turns out that it is not possible to overcome mis|unconfigured firewalls with more liberal tracker policy and/or client configs, it becomes a question of whether there are enough users able and willing to jump through the hoops to make offering the service worthwhile (main distribution method or not). I dunno how to determine that, but active torrents of Debian .iso's do exist, see: http://www.torrentz.com/search_debian - Bruce [1] to ensure the network is not used to distribute non-Debian stuff [2] 50,000 ports... to complicate port based bandwidth limiting or filtering? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Fri August 25 2006 03:46, Mgr. Peter Tuharsky wrote: > I cannot 100% agree with You, althought Your point is for sure > partially valid. Uhm, Debian's target audience is not Joe User, never has been AFAICT. Joe isn't usually capable of determining which MTA, web server, proxy server, etc., specific implementation is best for them, assuming they are even aware of the architecture underlying the UI they see... Debian assumes all of that of its users. Since my very first read of the Social Contract, Policy papers, etc., I have had the impression that Debian is not a "solution", it is the pieces one needs to build a solution. Taking this view explains a lot about Debian, and does so at a deeper level than some of the common perceptions. e.g.: Why there are so many CDD's and derivatives, with NGOs and even governments basing their OS on Debian. Is it just "the best", or has it been designed to accommodate such use. Why licensing which allows users to redistribute modified versions is so important. Are they all "free" fanatics, or would not being redistributable make the effort put into being easily derivable a waste of time. Why there are so many different implementations of pretty much everything in the archive. Does Debian lack focus, or is it just not possible to service all the potential users with just one or two implementations. Why the "learning curve" is so steep. Do Debianites want to be "elite", or is it simply that relatively few computer users are aware of the low level OS issues Debian necessarily deals with by catering to everybody. Why "old" software is commonplace. Slow and lazy with the packaging... or does it just take time to get all the pieces functioning well enough to be an easily derivable basis, and one which changes every six months would be a poor choice for that use. I agree with you 100% that Ubuntu is more focused on and better serves Joe User, but to say that `Debian doesn't care' is as wrong as you can be. Common perception appears to be much as you have written, the reality is that Debian has done such a good job at presenting a necessarily complex and contradictory collection of software that Joe User can actually be fooled into thinking it was done for them! I'm not saying Joe User is a fool, I am Joe everytime I "install" something and experience the learning curve of figuring out what it does and how I can use it. The Debian User's learning curve is a bit different though, it is one of recognizing where the needs of Joe, Corporate, NGO, etc. Users diverge and consequently where to look for the tools and tweaks needed to transform the universal OS into their OS. That there also needs to be tweaks at the "Arbitrary User" level afterwards should be no surprise and may well be unavoidable... that is where Ubuntu, Progeny, etc., enter the picture. The way I see it: distros tailored to specific types of users which are based on Debian are not making up for Debian's failings, they are the most natural and may even be the actual intended use of what Debian provides. HTH - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Sun August 27 2006 06:47, Sander Marechal wrote: > Hendrik Sattler wrote: > > It's all about expectations. Always keep in mind that the target > > group differs a lot between Ubuntu and Debian. > > I wouldn't say they differ. Ubuntu targets only a small subset of > Debian users. Maybe Debian should simply split the Desktop task in > tasksel into two entries: `Ubuntu users are a subset of Debian users' Yes, because both, Debian targets all users and Ubuntu is a Debian user. No, because Ubuntu clearly serves a group that Debian doesn't. > * Desktop - basic: Simple minimal GNOME installation pretty much as > it is now, maybe with even less software preinstalled. (I was > surprised by the ammount of software that came along with it). > > * Desktop - stand alone: End-user desktop enviroment where we can > safely add fancy integration tricks and extra components that Ubuntu > does as well. If by "we" you mean Debian... great success in that endeavour would essentially put Ubuntu out of business, I don't think that is what either wants. Debian should provide the means for Ubuntu to add "fancy integration tricks and extra components" in a safe way. Technically, "the means" boils down to the infrastructure and abstractions needed to trivially fork a *Debian* package (rather than create an *Ubuntu* package.) It would be really cool if Debian's "Ubuntu Desktop" task resulted in an Ubuntu Desktop system; an even better result would be a Debian system with the appropriate sources, pinnings, and configs needed to replicate an Ubuntu Desktop for just those things Ubuntu does differently. Ubuntu's installer would presumably result in a streamlined and focused system, while Debian would be capable of producing and managing a blend of Ubuntu's desktop, Whoever's server, whatever, etc., as required. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Sun August 27 2006 18:55, you wrote: > Deferring to Ubuntu for this work is the worst sort of defeatist > nonsense and I will not to bow to it. I like collaborating with the > Ubuntu people, but I refuse to compromise my own work or Debian as a > project just so that they can excel. I think you missed the point, Ubuntu's work would then be part of Debian rather than superceding or conflicting with what Debian does. Instead of Debian annoying its users by adopting Ubuntu-like feature, or annoying Ubuntu by not doing so, everyone would be able to get what they want within a reusable framework. Keep in mind that if Ubuntu is able to easily bend Debian to its will and create a top-notch desktop, anyone else can do it to... including Debian. No need to throw in the towel or compromise anything. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
[sorry for the duplicate, but I want to fix the threading] On Sun August 27 2006 18:55, David Nusinow wrote: > Deferring to Ubuntu for this work is the worst sort of defeatist > nonsense and I will not to bow to it. I like collaborating with the > Ubuntu people, but I refuse to compromise my own work or Debian as a > project just so that they can excel. I think you missed the point, Ubuntu's work would then be part of Debian rather than superceding or conflicting with what Debian does. Instead of Debian annoying its users by adopting Ubuntu-like feature, or annoying Ubuntu by not doing so, everyone would be able to get what they want within a reusable framework. Keep in mind that if Ubuntu is able to easily bend Debian to its will and create a top-notch desktop, anyone else can do it to... including Debian. No need to throw in the towel or compromise anything. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
On Wed August 30 2006 02:52, Subredu Manuel wrote: > Josselin Mouette wrote: > > Le jeudi 17 août 2006 à 11:48 -0400, Anthony L. Bryan a écrit : > > > > Given that downloads like Debian ISOs are already putting a heavy > > bandwidth load on the servers and that they are already shared > > among many servers, I don't think it is a good idea to encourage > > users to load several servers at once with one download. We should > > instead push bittorrent as the main distribution media for ISOs. > > I don't think you got the picture. Metalink can contain information > for download using the following protocols: > *) http > *) ftp > *) bittorrent > *) e2k <...> You seem to be ignoring that metalinker will use multiple protocols, servers, and connections in an effort to get the fastest download. http://www.metalinker.org/Metalink_3.0_Spec.pdf also indicates it will switch servers if the download rate falls, and perhaps even perpetuate old torrents --- which is all great for the client, but will pretty much guarantee worse than possible performance from the servers. It is also not clear what will happen when a release is made and hundreds (thousands?) of clients hit the fastest mirror, whose download rate then drops, prompting all the clients to try switching to the new fastest mirror, whose rate then drops, ... At the very least there will be more overhead traffic for the servers, worst case could be some kind of nasty cyclic oscillations with the server loads which undermines transfer efficiency for everyone. Ya, that's kinda FUDish, but given the newness and limited deployment of the technology, speculation is about all we have to work with. The objective is to ease and spread out the load on the servers; bittorrent and socially engineered access to the less efficient protocols is more likely to do that than bittorrent + ftp + http + multiple servers/client. IMO I think Metalinks are an interesting idea which deserve investigation, but it seems clear they would result in more server overhead and unclear whether the load spreading would offset that or even happen[1]. - Bruce [1] could clients be attracted to a few fast ftp servers and the often slow-to-start torrents end up being underutilized... the exact opposite of what is best for Debian's servers.
Re: Debian ISOs
On Thu August 31 2006 00:27, Subredu Manuel wrote: > Bruce Sass wrote: > > It is also not clear what will happen when a release is made and > > hundreds (thousands?) of clients hit the fastest mirror, whose > > download rate then drops, prompting all the clients to try > > switching to the new fastest mirror, whose rate then drops, ... At > > the very least there will be more overhead traffic for the servers, > > worst case could be some kind of nasty cyclic oscillations with the > > server loads which undermines transfer efficiency for everyone. > > Ya, that's kinda FUDish, but given the newness and limited > > deployment of the technology, speculation is about all we have to > > work with. > > When a new release is made, all servers (and mirrors) are getting > hit. First, the tier 1 (ftp..debian.org), and then the other > mirrors. Would each mirror or region need a unique metalink file to ensure that happens? I'm thinking that if all clients see the same metalink file they will all hit the same servers, and someone wanting to support the local mirrors could start fetching from 1/2-way around the world (I suppose there would still need to be non-metalink access just for this reason.) Hmmm, that brings up another question. Each downloadable file would need its own metalink file. How much space will that take and at what point would it become significant. > So, if you only consider http and ftp, metalink is the > logical choice, since it switches automatically to a new server, when > the rate drops (at least, it should, but this depends on the client). Transfers in progress could change servers, or new clients would get a different server? The former is what I would be concerned about (additional overhead, exacerbated by poorly coded or configured clients); the latter would be a good thing but could also be done with a smart round-robin setup (maybe already is via http.us.debian.org.) > The only situation in which you can save the servers bandwidth is > when you use download protocols that involves the users bandwidth, > like bittorrent, edonkey and other specifica file sharing protocols. > So, there are 2 situations here: > *) make .torrent files > *) make .metalinks files only with bittorrent, e2k protocols and > magnet urls > > You can see that metalink has advantage over bittorrent simply by > having bittorrent _and e2k_ :) Ya, assuming both are eventually made available from Debian. > > The objective is to ease and spread out the load on the servers; > > bittorrent and socially engineered access to the less efficient > > protocols is more likely to do that than bittorrent + ftp + http + > > multiple servers/client. IMO > > ok. then use metalink only with bittorrent and e2k links :) > I only try to convince you that using this technology is just a very > big advantage for the average joe. Nothing wrong with that. I did much the same thing back in '95(?) with http when Debian only provided ftp access to the archives (got told that http was too inefficient. :-) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
Hello Anthony,
Thanks for the response.
On Thu August 31 2006 12:17, you wrote:
> Hi Bruce, just wanted to say thanks for investigating Metalink. These
> are all valid concerns. For the last few months, the only big user of
> Metalinks has been OpenOffice.org, and I haven't heard any complaints
> from mirror/server admins. That doesn't mean there aren't any. I'm
> sure there will be problems, and I'd like to work them out as soon as
> possible.
>
> Metalink allows for information on the country location ("location")
> of a server along with priority ("preference"):
>
> location="au"
>preference="30">
>
> ftp://mirror.pacific.net.au/OpenOffice/stable/2.0.3/OOo_2.0.3_LinuxIn
>tel_ins tall.tar.gz
>
>
> The simplest way might be for clients to try local mirrors, in order
> of preference, then all other mirrors in order of preference (or,
> other close countries). I think this added information of location
> and priority will lead to more efficient use of bandwidth over just
> plain links (hopefully).
I think you are correct, provided the clients prefer local mirrors and
don't start casting around all over the 'net looking for a "great"
server without good reason (whatever that may be. :-)
> Manuel has also made a web interface that generates Metalinks
> depending on what country you select.
>
> Metalinks can list multiple or single files.
>
> The size of Metalink files depends on how much information you want
> to include and how many mirrors are listed. For example, Metalinks
> listing every kernel.org or OOo mirror are around 20k. All mirrors
> for Fedora ISOs: 54k, Ubuntu ISOs: 58k, SUSE ISOs: 10k.
Hmmm...
[quick manual counts, therefore approximate numbers]
Ubuntu has ~100 mirrors
(http://www.ubuntu.com/download)
Debian has ~36 primary + ~255 secondary mirrors
(http://www.debian.org/mirror/list)
which indicates that a Metalink file for Debian could be over 150k;
(for CDs) x 12 (11 arches and source) x (>)15 images per release.
Giving ~9M of HDD overhead if each download needed its own Metalink
file, <2M for one Metalink file per release, with reality somewhere in
between.
...so: HDD space shouldn't be a problem. It wouldn't be that simple
though because Debian mirrors are not necessarily identical and Ubuntu
appears to only have 3 or 4 arches with 3 images each on each mirror
(iow, mirror count aside, more complex Metalinks would be needed.) How
well the clients handle large numbers of is likely to be
significant and could affect how many can be reasonably
stuffed into a single Metalink; some of Debian's arches are rather
limited wrt RAM and CPU cycles compared to modern standards, and
Debian's minimum system requirements are low compared to others.
A scheme which is only useful to an arbitrary subset of Debian
installations has less chance of being adopted than one which everyone
can use. "Arbitrary" in that there may be no clear dividing line
between `works' and `does not work' based on something other than the
size of the Metalink file, the dependencies it drags in, available RAM,
or other installation dependent variables (or whims). I'm not saying
this is a problem with Metalinks, but it could be a problem unique to
Debian and would need special attention.
> I'd be interested in working on any things that may be an issue for
> Debian as I'm sure they would affect others too.
>
> One thing I'd definitely like to do is get aria2
> (http://aria2.sourceforge.net/) included in Debian. It's a BitTorrent
> and Metalink command line client. Maybe recommending certain clients
> over another and working with the authors of those clients to be
> correctly coded and configured by default could help.
http://lists.debian.org/debian-mentors/2006/08/msg00197.html
I'm not sure why it hasn't appeared in Unstable yet.
[but it looks like Patrick does :-]
- Bruce
p.s. - I'm not on debian-cd, CC me if you want.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat September 16 2006 16:56, Petter Reinholdtsen wrote: > [Steve Langasek] > > > However, that's not the same thing as saying it's ok for sysvinit > > to *make* /var/run a tmpfs on the admin's behalf. I think it's > > pretty clear that this violates the letter of the FHS, and such a > > change needs to be considered carefully. > > I fail to see how it violates the letter of the FHS. It is as far as > I can see unspecified what kind of file systems will be used, and > also if directories will persist across boots. > > The reason I believe it is important to have some writable file > system available at the very beginning of the boot is that there are > programs running when kernel modules are loaded by udev that need a > place to store state information. At the moment, there is no > location to do that, and strange things can happen when the coldplug > events happen early in the boot. To fix it, some tmpfs area need to > be mounted in mountkernfs.sh. This issue has been discussed here on > the list a few months ago, without any conclusion being reached. I > do not want us to release etch with a boot system unable to handle > detected hardware properly, so I decided to fix this now. Also, it > is useful to make it easier to set up stateless workstations using > Debian (aka diskless machines ala LTSP), and storing state > information in a RAM file system make this a lot easier. Sounds fine, if one has enough RAM to spare. How big can /var/run get? Could such a change limit the usefulness of low mem systems? Is it feasible to create a tmpfs based /var/run during boot then move its contents to a disk based /var/run (if that is the admin's the preference) when /var becomes available? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
On Sat October 21 2006 13:35, Darren Salt wrote: > I demand that Hendrik Sattler may or may not have written... > > 64bit kernels are not available in the i386 archive. That makes the > > 64bit libs rather useless, doesn't it? > > No - you could be using a locally-built 64-bit kernel. Perhaps i386 needs something along the lines of localepurge for 64bit stuff. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sun October 22 2006 23:22, Manoj Srivastava wrote: > I still think we should go for quality of implementation. > > I also seem to be a minority in this regard. I sincerely hope not. > If the project feels that we should downgrade policy not to > set our maintainer scripts to allow for the admin to set /bin/sh to > be not bash, they can file a bug on policy, and so indicate their > belief on the bug reprot; I'll reluctantly degrade policy. As long as Debian allows alternatives to /bin/sh -> /bin/bash, the only bugs which should be filed, afaict, are those against packages whose scripts specify /bin/sh and fail to work with any "sh" but bash... clearly they are buggy and should be specifying /bin/bash as their command interpreter. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Mon October 30 2006 16:46, Javier Fernández-Sanguino Peña wrote: <...> > However, confirming each spam I have > in my mailbox vs. the web interface is time consuming and slightly > frustating when you find that the spam had no opportunity to get in > (the bug was archived) or it was already removed (bad). How time consuming it is depends on the UI. I checked out and reported 70+ spam messages sent to packages (via [EMAIL PROTECTED]) handled by [EMAIL PROTECTED] a couple days ago (two batches) fairly quickly by using KDE's "run command" applet (averaging 8 keystrokes, 2 mouse movements, and two clicks, per message.) > PS: If abuse of that (e-mail) interface was of concern it could be > implemented so as to only consider GPG/PGP signed mail from DDs (I > don't see that the web interface takes any precaution against being > abused, from what I can tell, but a e-mail gateway is slightly more > easier to abuse) I have also been doing some bug cleaning in dselect recently (30+ bugs closed or recalssified, only one which I ended up reopening), something which would not be possible without pestering DD's if signed messages were required. I have yet to see a spam message sent to the BTS which used a "Package:" pseudoheader, so that should work to eliminate BTS spam without preventing non-DD's helping out. - Bruce
Re: Lots of (easily recognisible) spam sent to the BTS today
On Tue October 31 2006 21:15, Anthony DeRobertis wrote: > Bruce Sass wrote: > > I have yet to see a spam message sent to the BTS which used a > > "Package:" pseudoheader, so that should work to eliminate BTS spam > > without preventing non-DD's helping out. > > OTOH, a /lot/ of legitimate mail is sent to the BTS w/o a Package: > pseudo-header (think: pretty much anything to > [EMAIL PROTECTED]). So this isn't really a solution. I don't think that disqualifies it as a solution, it just means there would be a transition period while users learn that it is a required part of messages sent to the BTS. But let's see how the new SA rules work before imposing any specific requirements on BTS messages, or (especially) requiring a particular browser based UI or program be used to interact with the BTS. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Tue October 31 2006 23:02, Don Armstrong wrote: > On Tue, 31 Oct 2006, Bruce Sass wrote: > > On Tue October 31 2006 21:15, Anthony DeRobertis wrote: > > > Bruce Sass wrote: > > > > I have yet to see a spam message sent to the BTS which used a > > > > "Package:" pseudoheader, so that should work to eliminate BTS > > > > spam without preventing non-DD's helping out. > > > > > > OTOH, a /lot/ of legitimate mail is sent to the BTS w/o a > > > Package: pseudo-header (think: pretty much anything to > > > [EMAIL PROTECTED]). So this isn't really a solution. > > > > I don't think that disqualifies it as a solution, it just means > > there would be a transition period while users learn that it is a > > required part of messages sent to the BTS. > > It has all of the same types of problems as sender verification > anti-spam techniques; increasing the number of hoops that users have > to hop through decreases the likelihood of them actually reporting > spam. (assuming you mean, `likelihood...reporting bugs') I don't think it is as bad because there would be no need to keep a "white list" to avoid a verification message, and the verification could be dropped once it is common knowledge that a Package: pseudoheader is required (say, after one release cycle.) > Decreasing the score at which we ignore messages is trivial, but it > means increasing the number of false positives. [And because > backscatter is bad, these will be messages which just "disappear", > unless some (massochistic) person actually goes through the spam > mailboxes.] Ya. I generally don't like anti-spam techniques because they require either the sender or recipient to jump through hoops, or are prone to false positives... but limiting interaction with the BTS to pre-verified users (as requiring signed messages by DD's would do) is an even smaller (as in harder to jump through) hoop than requiring a specific, easily reproduced with any MUA, format for messages sent to the BTS. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Wed November 1 2006 16:20, Javier Fernández-Sanguino Peña wrote: > When I have suggested that (sending signed messages to the BTS to be > accepted for processing) it was > > a) for mails to -close or to [EMAIL PROTECTED] to prevent a > spammer/malicious person from closing all the bugs or mangling with > the BTS in such a way that would take us some effort to recover > > b) restricted to providing a signed mail, not necessarily with a > signature in the DD keyring. (this could be added later on to prevent > abuse, if needed be and could still have a 'whitelist' of valid keys > which could include non-DDs) > > If there's a non-DD playing with the BTS (closing bugs or using > control@) I guess it's not really too much to ask for them to use > signed e-mails when fiddling with it. Is it? I don't think so. Although, it is weaker than a pseudoheader since it would be easier for spammers to sign their messages than look up the package name associated with a particular bug number, and less effort than keeping a whitelist. Furthermore, it would be clear that a spammer was targeting Debian if they did the name<->number look up... which would make it easier to make a case that they are intentionally interfering with Debian's systems. Keep in mind that my original response was to your post which stated: "...implemented so as to only consider GPG/PGP signed mail from DDs..." - Bruce
Re: 2 ftpds packages conflicts
On Tue November 7 2006 04:51, [EMAIL PROTECTED] wrote: > Yet there are also many users, probably those who are not > professional administrators, that _need_ for everything to work out > of the box. Who should we help more: those who get paid to administer > the machines, and are probably much more knowledable, or the > occasional, home or small office user that doesn't have the knoweldge > or the time to acquire it? Those users should be using a derivative whose business is to help. another way to look at it... Should Debian force professionals to jump through hoops for the sake of users with limited knowledge and no inclination to learn about the system they are using. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Fri November 10 2006 02:36, Bill Allombert wrote: > On Fri, Nov 10, 2006 at 12:01:10AM -0600, Manoj Srivastava wrote: > > Hi, > > > > Firstly, should we be pointing to the SuS instead of POSIX > > (there is work going on a new version of the SUS), since it is > > open, and readily available on th 'net, and people can readily see > > it (as opposed to people who have shelled out $500 for a version)? > > Very much agreed. I don't think Debian policy should mention non-free > documents, and certainly not documents unavailable to developers. Sounds right, and proper, given Debian's focus on freeness. So, why POSIX... history, completeness? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sat November 11 2006 22:10, Manoj Srivastava wrote: > So why not just specify all maintainer scripts just use > /bin/bash? I am not sure. Perhaps because allowing scripts to > specify /bin/sh would allow then to be sped up a trifle when /bin/sh > is a nimbler shell? Is this worth the complexity? we speed up > install times of packages a wee bit at the expense of a much more > complicated policy document? (I know some people think we can move > bash out of Essential one of these days, and well, I think that is > mere wishful thinking and a pipe dream). "trifle" and "wee" for a modern box can be significant on an older box, in both start up time and the amount of RAM used. I think Debian should specify that maintainer scripts must use /bin/dash... that would also cut down on policy complexity, and not unnecessarily raise the bar with respect what is required to be a usable system. How many more bugs like #271072 and #395140 will be filed if /bin/bash use was mandated for maintainer scripts? What does bash do that can't be done with dash? Should convenience trump usability? What would be more noticeable or significant: the 200k dash package on a modern box, or increased swapping and significantly slower installs on an older one? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue November 14 2006 19:06, Thomas Bushnell BSG wrote: > I refused to stop using test -a in my packages as well, and refused > to declare #!/bin/bash. > > Here's why. > > test -a is not a "bashism". > > It's a feature of the Debian test program. It happens that bash > declares a builtin, but that's irrelevant. Bash's builtin is > compatible with the Debian test, and *that's* relevant. > > Some /bin/sh programs happen to *override* the Debian test builtin, > and do so *in incompatible ways*. If those /bin/sh programs did not > declare a test builtin, there would be no problem: my scripts would > get the Debian implementation of test, and everything would be fine. Is moving the test executable to /bin with a symlink to /usr/bin (so existing scripts which already use a path continue to work) then requiring /bin/test a solution? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed November 15 2006 10:23, Thomas Bushnell BSG wrote: > On Wed, 2006-11-15 at 14:40 +0100, Gabor Gombas wrote: > > * test.c: New file, from bash. > > > > So you in fact _are_ using a bash feature, and there was a time > > when /usr/bin/test did not even exist (but hey, neither did Debian > > :-) > > The *file* comes from bash. The *feature* does not. Since the file was used to provide both the bash builtin and the standalone test, and -a is undocumented in the test manpage, it is most likely a bash feature... why not use -e, which is documented and available in dash, bash, and test? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed November 15 2006 15:08, Russ Allbery wrote: > Bruce Sass <[EMAIL PROTECTED]> writes: > > Since the file was used to provide both the bash builtin and the > > standalone test, and -a is undocumented in the test manpage, it is > > most likely a bash feature... why not use -e, which is documented > > and available in dash, bash, and test? > > That's not the -a that we're talking about; that's the unary -a and > we're talking about the binary -a. Use of -a as a binary operator is > part of the XSI extension of POSIX/SUS and is definitely not specific > to bash. I don't know enough about shell history to know who came up > with it initially, but it would surprise me if it were bash. Hmmm, I guess I'm confused by Thomas's statement... "I refused to stop using test -a in my packages as well, and refused to declare #!/bin/bash." ...and the fact that dash, bash, and test, all document their binary -a operator as having the same behaviour. Is their some Bourne style command interpreter other than dash in Debian which offers to provide "sh"? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed November 15 2006 16:45, Russ Allbery wrote: > Bruce Sass <[EMAIL PROTECTED]> writes: > > Hmmm, I guess I'm confused by Thomas's statement... > > > > "I refused to stop using test -a in my packages as well, and > > refused to declare #!/bin/bash." > > > > ...and the fact that dash, bash, and test, all document their > > binary -a operator as having the same behaviour. > > > > Is their some Bourne style command interpreter other than dash in > > Debian which offers to provide "sh"? > > No, but Policy currently requires scripts that use features not > available from POSIX to declare an appropriate shell, and POSIX > doesn't guarantee the binary -a operator. Since all sh's in Debian provide compatible binary -a operators, #!/bin/sh is appropriate when that operator is used and Policy is not being violated. Ya? > The reason why I started this whole thread was because every shell > that people use in practice as /bin/sh does support that operator, > and I don't think that we're realistically likely to get all the > shell scripts in Debian to change to not assume that when it doesn't > cause problems in practice. I don't see why scripts would need to change. I can see how mention of -a in Policy could be considered as cruft, but it would serve to identify -a as a requirement, in addition to POSIX, which any command interperter in Debian purporting to be "sh" needs to abide by... is that what you are trying to get clarified? Sorry, I got lost trying to follow all the diffs to Policy I've seen. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed November 15 2006 18:15, Russ Allbery wrote: > Bruce Sass <[EMAIL PROTECTED]> writes: > > On Wed November 15 2006 16:45, Russ Allbery wrote: > >> No, but Policy currently requires scripts that use features not > >> available from POSIX to declare an appropriate shell, and POSIX > >> doesn't guarantee the binary -a operator. > > > > Since all sh's in Debian provide compatible binary -a operators, > > #!/bin/sh is appropriate when that operator is used and Policy is > > not being violated. Ya? > > I suppose you could read it that way, but I think that's strained. > > The standard shell interpreter /bin/sh can be a symbolic link to > any POSIX compatible shell, if echo -n does not generate a > newline.[59] Thus, shell scripts specifying /bin/sh as interpreter > must only use POSIX features. If a script requires non-POSIX features > from the shell interpreter, the appropriate shell must be specified > in the first line of the script (e.g., #!/bin/bash) and the package > must depend on the package providing the shell (unless the shell > package is marked "Essential", as in the case of bash). > > I'd rather make the situation clearer. No doubt. I've always thought that, historically, "sh" was a Bourne shell... ignore history at your own peril. > > I don't see why scripts would need to change. I can see how mention > > of -a in Policy could be considered as cruft, but it would serve to > > identify -a as a requirement, in addition to POSIX, which any > > command interperter in Debian purporting to be "sh" needs to abide > > by... is that what you are trying to get clarified? > > Yup! I can understand Debian wanting to be POSIX compliant and dictating that /bin/sh be POSIX compliant, but it is an error to say that any POSIX compatible shell is a "sh". e.g., pdksh claims to be POSIX compatible and it may be appropriate to allow it to link to /bin/ksh, but surely it would not be proper to link pdksh to /bin/sh even though Korn claims to be Bourne compatible. AFAICT, "/bin/sh can be a symbolic link to any POSIX compatible shell" does not really convey what Debian wants, it would be better to state that, `only POSIX features should be used in Debian "sh" scripts', followed by a list of exceptions (which would presumably be a subset of those features in common use which exist in all shells allowed to be "sh".) So, maybe something like: - Scripts specifying /bin/sh as their command interpreter (shell) must only use SUSv3[1] features or the following exceptions: - echo -n[2] - [ x -a y ] [3] - ...[4] Thus, the only shells allowed to be /bin/sh are those which are SUSv3 compliant and implement the allowed exceptions to SUSv3. If a script requires non-SUSv3 features not explicitly excepted, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked "Essential", as in the case of bash). [1] http://www.opengroup.org/onlinepubs/009695399/ POSIX, XSI, whatever [2] whatever its problem is [3] why -a is allowed [4] justification as to why or why not - I think the above text has the advantage of being clearer about what is expected of scripts, after all, it is the scripts that are important and the shells can be anything able to properly interpret them. It also puts any exceptions to the desired conformance in a list separated from the main text, which allows for easy modification and serves as a quick reference of things which need to be eliminated for compliance to be achieved. The exceptions can be crossed off and their justification deleted as they become irrelevant without altering the text itself, eventually ending up with something like: - Scripts specifying /bin/sh as their command interpreter (shell) must only use SUSv3[1] features. Thus, the only shells allowed to be /bin/sh are those which are SUSv3 compliant. If a script requires non-SUSv3 features, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked "Essential", as in the case of bash). [1] http://www.opengroup.org/onlinepubs/009695399/ POSIX, XSI, whatever - Thanks for your time, and HTH. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed November 15 2006 17:08, Thomas Bushnell BSG wrote: > On Wed, 2006-11-15 at 16:28 -0700, Bruce Sass wrote: > > Hmmm, I guess I'm confused by Thomas's statement... > At that point, I suggested and still suggest that we change Policy to > restrict /bin/sh to a specific set of shells, rather than just any > "Posix-compatible shell". > > But Policy currently requires correct operation for any > Posix-compatible shell, not just those shipped in Debian. You might, > I'm guessing, agree with me that simply giving a list would solve the > problem, as indeed, it would. That's my preferred solution. It would, but at the expense of POSIX compliance or, if POSIX is retained as a goal, pushing the compliance determination step into a new piece of policy which defines which shells get added to the list... getting us little. I don't think Policy is wrong in pushing for POSIX compatible shells, just poorly worded and perhaps focusing on the shell instead of the scripts. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed November 15 2006 21:50, Manoj Srivastava wrote: <...> > This does specify what the scripts may expect, but drops all > wording from this section regarding what the policy expectation of > /bin/sh is. I was going to do that, then added it back in because it is implied and explicit is better than implicit. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Thu November 16 2006 11:06, Thomas Bushnell BSG wrote: > On Thu, 2006-11-16 at 04:14 -0700, Bruce Sass wro > > > AFAICT, "/bin/sh can be a symbolic link to any POSIX compatible > > shell" does not really convey what Debian wants, it would be better > > to state that, `only POSIX features should be used in Debian "sh" > > scripts', followed by a list of exceptions (which would presumably > > be a subset of those features in common use which exist in all > > shells allowed to be "sh".) > > The problem is that "POSIX feature" is a meaningless term in this > context. I see your point. > If "test -a" is not a POSIX feature (or any other random test > arguments bandied about here), then so calling "debconf" is also not > a POSIX feature, and for exactly the same reason: either might be > overridden by a builtin. "test" is included in the spec, so a script's use of "test" should be restricted to features included in the spec of "test" for the script to be compliant with the spec. "debconf" is not included in the spec, so use of it can not be non-compliant because it is impossible to not comply with something which doesn't exist. So, maybe something alone the lines of: The use of commands included in the spec must comply with the spec of those commands. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Thu November 16 2006 18:23, Manoj Srivastava wrote: > On Thu, 16 Nov 2006 17:40:20 -0700, Bruce Sass <[EMAIL PROTECTED]> said: > > On Thu November 16 2006 11:06, Thomas Bushnell BSG wrote: > >> The problem is that "POSIX feature" is a meaningless term in this > >> context. > > > > I see your point. > > I don't, but really, I am not sure I ought tobe spending much > more time on an arcane reading of this corner case. "POSIX feature" could be read as referring to only those features mentioned by POSIX, period. I don't think that is a reasonable interpretation because it implies that stuff like, say, debconf, is out since it is not mentioned by POSIX---but it is ambiguous. > The issue, apparently, is that under policy, some shell can > come up with all kinds of shadowing of things like debconf. I > suggest that if brought before the TC, the TC shall decide that is a > bug in the shell. Policy is not supposed to be written to specify > all kinds of silly and deliberate malice on the part of shell > authors. Policy should be clear though. > > The use of commands included in the spec must comply with the spec > > of those commands. > > O, good grief. This is not Law 101. This is the technical > policy all kinds of non native developers must read, understand, and > follow; arcane corner cases and increasingly complex language to > resolve corner cases just makes policy asinine, turgid, obfuscated, > and abstruse. If packages can be tagged as RC buggy because of Policy violations then Policy is law. Other than that, I agree. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sun November 19 2006 14:03, Thomas Bushnell BSG wrote: > On Sun, 2006-11-19 at 18:43 +0100, David Weinehall wrote: > > On Sat, Nov 18, 2006 at 08:01:04AM -0800, Thomas Bushnell BSG wrote: > > > On Sat, 2006-11-18 at 11:30 +0100, Andreas Metzler wrote: > > > > > Well, the goal was (in part) to catch scripts which use > > > > > non-Posix features of echo and test; why are non-Posix > > > > > features of ls not an issue? > > > > > > > > > > > > Since I cannot think of a legitimate reason for anyone to use > > > > ls in a shell script, I think it would add little value. > > > > > > > > > > Makes you wonder why it's in Posix.2 at all, huh? (Posix.2 is > > > about scripts, not user interaction.) > > > > "The ls utility shall conform to the Base Definitions volume of > > IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines." > > > > It's a *utility*, not a shell function. > > Right. "test" and "echo" are also defined as utilities, not shell > functions. IEEE Std 1003.1, 2004 Edition, section 2.14: "The term "built-in" implies that the shell can execute the utility directly and does not need to search for it. An implementation may choose to make any utility a built-in..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sun November 19 2006 15:05, Thomas Bushnell BSG wrote: > On Sun, 2006-11-19 at 14:53 -0700, Bruce Sass wrote: > > On Sun November 19 2006 14:03, Thomas Bushnell BSG wrote: > > > On Sun, 2006-11-19 at 18:43 +0100, David Weinehall wrote: > > > > On Sat, Nov 18, 2006 at 08:01:04AM -0800, Thomas Bushnell BSG wrote: > > > > > On Sat, 2006-11-18 at 11:30 +0100, Andreas Metzler wrote: > > > > > > > Well, the goal was (in part) to catch scripts which use > > > > > > > non-Posix features of echo and test; why are non-Posix > > > > > > > features of ls not an issue? > > > > > > > > > > > > > > > > > > Since I cannot think of a legitimate reason for anyone to > > > > > > use ls in a shell script, I think it would add little > > > > > > value. > > > > > > > > > > Makes you wonder why it's in Posix.2 at all, huh? (Posix.2 > > > > > is about scripts, not user interaction.) > > > > > > > > "The ls utility shall conform to the Base Definitions volume of > > > > IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines." > > > > > > > > It's a *utility*, not a shell function. > > > > > > Right. "test" and "echo" are also defined as utilities, not > > > shell functions. > > > > IEEE Std 1003.1, 2004 Edition, section 2.14: > > "The term "built-in" implies that the shell can execute the utility > > directly and does not need to search for it. An implementation may > > choose to make any utility a built-in..." > > Right. Just like ls, or debconf. ls is covered by the spec, debconf is not so there is nothing for it to conform, or not, to. > Posix puts grep, ls, kill, test, and echo all in *exactly the same > category*. So why does posh treat them so differently? In the case of ls, because the author "cannot think of a legitimate reason for anyone to use ls in a shell script", and he thinks "it would add little value." Presumably grep is in the same boat. > Why is > catching non-Posix uses of test and echo important, and non-Posix > uses of ls grep not important? I would expect that sh scripts which use non-spec'd features of ls or grep would be open to receiving bug reports for violating Policy. Why do you think that is not the case? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sun November 19 2006 15:59, Thomas Bushnell BSG wrote: > On Sun, 2006-11-19 at 15:47 -0700, Bruce Sass wrote: > > > Posix puts grep, ls, kill, test, and echo all in *exactly the > > > same category*. So why does posh treat them so differently? > > > > In the case of ls, because the author "cannot think of a legitimate > > reason for anyone to use ls in a shell script", and he thinks "it > > would add little value." Presumably grep is in the same boat. > > Care to know how many scripts in Debian call grep? I checked. It's > not a small number. looks like I presumed wrong for grep, eh > > > Why is > > > catching non-Posix uses of test and echo important, and non-Posix > > > uses of ls grep not important? > > > > I would expect that sh scripts which use non-spec'd features of ls > > or grep would be open to receiving bug reports for violating > > Policy. Why do you think that is not the case? > > Because Policy does not mandate compliance with arbitrary Posix > implementations. How can a POSIX implementation be anything but non-arbitrary. > It mandates this only for the shell, no, for scripts using #!/bin/sh > under the > illusion (apparently) that there is some sense to saying "you can > only use Posix shell features" and "you are free to use Debian > features of Debian programs". close... try: There is some sense to saying "you can only use Posix features when the spec includes the commands the features are part of" and "you are free to use Debian features of Debian programs". > The fact that the shell does not happen to declare any random Debian > command as a builtin, and then do something weird with it, is also a > non-spec'd feature of the shell. So by your reasoning there is > almost no #!/bin/sh shell script in Debian which does not violate > Policy. No, by my reasoning, commands not covered by the spec can not violate the spec. > Clearly Policy must not be read in such a way that nearly every > script violates it. Exactly, so why do you read Policy with respect to Debian features not covered by the spec as doing so? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Thu November 23 2006 13:56, Jari Aalto wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > "bash" is a better shell for most users, since it has some nice > > features absent from "dash", and is a required part of the system. > > This refers to inteactive use. dash suits well for scripts. Straddling the line somewhat is GIT. Installing dash to provide sh and setting GIT_SHELL to /bin/sh results in a noticeable improvement on even a 1GHz box. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Fri November 24 2006 13:15, Thomas Bushnell BSG wrote: > Instead of focusing and hammering again and again on /bin/sh, why not > instead ask maintainers to do #!/bin/dash? because bash offers a larger superset of sh features than dash, and "sh" is a standard part of System V-like unix systems like Linux > There may well be advantages to dash for this or that application. > So then, maintainers should be encouraged to use it. The best way, > of course, is #!/bin/dash. and stop using "sh" altogether, or should the www.emdebian.org people fork the entire distribution? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Fri November 24 2006 14:42, Thomas Bushnell BSG wrote: > On Fri, 2006-11-24 at 14:03 -0700, Bruce Sass wrote: > > On Fri November 24 2006 13:15, Thomas Bushnell BSG wrote: > > > Instead of focusing and hammering again and again on /bin/sh, why > > > not instead ask maintainers to do #!/bin/dash? > > > > because bash offers a larger superset of sh features than dash, and > > "sh" is a standard part of System V-like unix systems like Linux > > But #!/bin/sh scripts aren't allowed to use those. What I'm saying > is that the energy spent on making rules about #!/bin/sh would be > better spent encouraging people to simply switch--when > appropriate--to #!/bin/dash. If someone uses dash features not included in, both, the spec for "sh" and other Bourne shells allowed to become "sh", they should use #!/bin/dash. IMO. bash is in the same boat. > > > There may well be advantages to dash for this or that > > > application. So then, maintainers should be encouraged to use it. > > > The best way, of course, is #!/bin/dash. > > > > and stop using "sh" altogether, or should the www.emdebian.org > > people fork the entire distribution? > > What I said was that *if* it is better for a given script to run with > dash than with bash, the maintainer should be encouraged to say > #!/bin/dash. Sure, but since all "sh" scripts would be better off if they specified dash as their command interpreter... #!/bin/sh use would disappear. > I don't think it's my job to start saying what *other* distributions, > which are not Debian, should do. but it is Debian's job to be responsive to its users needs and Debian has made a choice to strive for susv3 compatibility - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Fri November 24 2006 15:24, Thomas Bushnell BSG wrote: > On Fri, 2006-11-24 at 15:12 -0700, Bruce Sass wrote: > > Sure, but since all "sh" scripts would be better off if they > > specified dash as their command interpreter... #!/bin/sh use would > > disappear. > > So? Just pointing out that encouraging #!/bin/dash instead of #!/bin/sh when a script would be better off with a lighter shell than bash results in the demise of #!/bin/sh. > > > I don't think it's my job to start saying what *other* > > > distributions, which are not Debian, should do. > > > > but it is Debian's job to be responsive to its users needs and > > Debian has made a choice to strive for susv3 compatibility > > I don't think you understand what "compatibility" means in this > context. It does not mean that you can substitute any component of > the system with a different standards-compliant version and > everything must continue to work. So, what does "compatibility" mean in this context? > Our users needs do not, by and large, include embedded systems. I am glad that "by and large" is not the standard, for that would make Debian somewhat less universal than it is. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Tue July 25 2006 05:38, Goswin von Brederlow wrote: > Except that libapt does NOT correctly handle dependency loops and can > split them between dpkg calls causing install failures. > > The more circular depends there are the more likely such a failure > becomes. So wouldn't it be a good thing to remove all the circular > depends that are not neccessary? Sure, but an even better thing would be to fix libapt. It sounds pretty arbitrary of libapt to split an install into batches based simply on size (assuming all the pre-depends, etc. have been looked after), and it is just plain not right to place arbitrary limits on the package archive because of failings in client software. If that is the root of the problem with circular dependencies, and it has been known for years, why haven't any of the obvious fixes[1] been implemented? - Bruce [1] "obvious" fixes, imo: - Heuristically remove potentially problematic packages from the batch. Eventually, either the afflicted packages will end up in the same batch or the last batch will be larger than what libapt wants to pass onto dpkg (the outcome of which is either the status quo or no-problem, depending mostly on how conservative the max size is on the target system.) The upside of this is that it is likely to be easy to implement as a filter function; the downside is that its inefficiency is magnified by the likelyhood of additional dpkg invocations. - Build chunks based on the structure of the dependency tree of the packages being installed. E.g., the first batch sent to dpkg would consist of independent packages (which only depend on stuff already installed) depended upon by multiple packages, next would come chunks of packages with dependency relationships, finally the independent packages which couldn't be used to fill up prior batches. The upside is that it would be a very interesting (as in fun) project [recursion, graphs, packing, accommodating multiple chunk'n'batch strategies (because it is unlikely the same one would work "best" for daily upgrades from unstable -> yearly dist upgrades of stable)], maybe a DB, what more could a programmer want, eh]; the downside is that it may also be interesting in a "Chineses curse" kinda way [see: http://www.noblenet.org/reference/inter.htm]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The nature of testing and where can others help (Was Re: HowTo for Gnome2??)
Hi, I accidentally deleted all the messages in my debian-user folder . However, I do remember enough of your original post to (hopefully) enlighten you. I have also done the nasty cross-post thing to -devel because I conclude with a thought on how to get the package pool living up to its potential. There is no way to show anyone what the next Debian will look like until it is released . ^^^ You can see which packages are being worked on for inclusion in the next release (those in unstable), but until the release is made there is no way to tell if a package will get enough of its known bugs fixed to be included. Even a package being in testing when a freeze comes along does not provide enough information with which to make that determination. Debian unstable, testing, and stable archives are not development, pre-release, and released archives... until a freeze comes along. Maybe this will help... Flow of new software into Debian's archives: 1 23 --- --- --- N) upstream+ ---> unstable ---> testing stable F) upstream+ ---> unstable testing stable R) upstream+ ---> unstable testing ---> stable 1, 2, and 3 represent the movement of packages; N, F, and R indicate Debian's "normal", "in a freeze", and "release" modes of operation; upstream+ represents the original source plus modifications made by a Debian developer; unstable, testing and stable are Debian archives. 1 can happen at any time and is controlled by the autobuilder; 2 can only happen between freezes and is controlled by the bug tracking system (BTS); 3 is a manually triggered operation whose timing is determined with input from the BTS and developers. To put it into perspective... once (only one or two releases ago) there was just unstable and stable, testing only existed during a freeze. Release cycles were too long and developers didn't like having to put development of new software on hold when a freeze came along, so they decided to do away with separate archives and move to a "package pool" system -- all packages actually exist in a common pool and specific versions are flagged as being included in one or more virtual archives. The idea being that developers could continue to develop at their own pace and relatively stable packages would automatically accumulate in testing, at some point testing would look good enough to freeze and then release as the current stable. Speculation/opinion: Why is testing in such bad shape... It seems to be the case that developers are moving packages through unstable too fast for testing to reach a point where it looks good enough to freeze and polish into a release. What could be done to fix the situation... Create a permanent "frozen" archive, fed from a consistent set of packages in testing which have been flagged as release candidates. By "set of packages" I mean all the packages which make up, for example, Gnome or Gnome2 or KDE2 or KDE3, etc. If only one version of a set is allowed to be a release candidate at any point during a release cycle, and only packages which have achieved stability are allowed to move into the frozen archive... "testing+frozen" will quickly become what users want "testing" to be (a peek at the next Debian), and the release manager only needs to look at the quantity of packages in frozen to determine if it is time (are all or enough of the release candidates here?). Useful Debian systems with the existence of a "frozen" archive... (where your sources.list lines point to) unstableDevelopers developing and users who don't mind bleeding from time to time. testing/unstableUsers who don't mind getting hurt as long as first aid is likely to be available. testing Crazy people, this could contain (for example) Gnome, Gnome2, KDE2 and KDE3, all at the same time! Basically a holding area for packages transitioning from development to pre-release. frozen/testing Developers polishing and users wanting a peek at the next release. frozen Anyone interested in how far along the next release has progressed. Stable quality, but not a complete distribution. stable most users Flow of new software within a Debian with a "frozen" archive: | --- development ---|--- pre-release ---|- released -| | phase| phase|| unstable --> testing -> frozen ---> stable, archived 1 23 0 - (not shown) flow into unstable, controlled by the autobuilder 1 - controlled by the BTS 2 - BTS (tighter restrictions than 1) and developer input via a release candidate flag 3 - BTS and release manager (who c
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
On Fri, 1 Aug 2003, Arnaud Vandyck wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > [...] > > [3] http://www.fs.tum.de/~bunk/Debian/freeze > > Reading the whole "Future releases of Debian" thread, I thought that > the main idea was that Debian need a more 'readable' status for the next > stable release. <...> While it would be nice to see at a glance how far along the next release is, the proposal doesn't address the real problem of the release cycle being too long... fix that and a more readable status of the next release would be moot. This has been an issue for as long as I can remember (I've been a Debian user since 1.3), creating a permanent testing archive was an attempt to solve it... but it hasn't worked because new software hits testing too fast for testing to stabilize enough to freeze (how long until the KDE packages in testing are a mix of 2.2, 3.1.2, and 3.1.3... two weeks?). I can only see two viable options: freeze at regular intervals and live with whatever happens to be in testing at the time, or extend the flow of packages paradigm all the way to stable. The first is like taking a 1/2 a step backwards (imo), the second requires another archive because testing can not work as both the output of unstable and the input for stable (it could if multiple versions of all packages could exist in the same archive at the same time). - Bruce
Re: [PROPOSAL] Debian Release Plan
On Fri, 1 Aug 2003, Chris Cheney wrote: <...> > Do we even know which packages in sarge have RC bugs? The last time I > looked when you close a bug with an upload to sid it closes it entirely > still. So we don't really have a good idea of how many RC bugs exist in > sarge, only how many are in sid. The BTS needs to adopt a "package pool" like mentality, where bugs are assigned to a particular version of a package instead of just the package. - Bruce
Re: Bits from the RM
On Wed, 20 Aug 2003, cobaco wrote: > I'd agree if there had been a rewrite of kdelibs or something, but kde 3.1 -> > 3.2 is evolutionary without big changes to what was already there. It does not take a big change to break software... e.g., openssh changed a message and the sftp kioslave broke http://bugs.kde.org/show_bug.cgi?id=51359 I think you are missing the point of "stable", and Debian's users who don't would be more disappointed with just released software in stable than with somewhat out-dated software. Keep in mind that if this experiment works, "testing" will end up being what you wish "stable" was, at least that is how I see it. - Bruce
Re: Bits from the RM
On Wed, 20 Aug 2003, Colin Watson wrote: > On Wed, Aug 20, 2003 at 11:18:24AM -0600, Bruce Sass wrote: > > On Wed, 20 Aug 2003, cobaco wrote: > > > I'd agree if there had been a rewrite of kdelibs or something, but > > > kde 3.1 -> 3.2 is evolutionary without big changes to what was > > > already there. > > > > It does not take a big change to break software... > > e.g., openssh changed a message and the sftp kioslave broke > > http://bugs.kde.org/show_bug.cgi?id=51359 > > Not that I disagree with you, but frankly, the sftp kioslave was already > broken. It should never have been written to depend on 'ssh -v' output. Ya, and it didn't manifest until a minor release of ssh or a patch release of KDE came along. ;-) - Bruce
Re: "non-free" software included in contrib
On Sun, 31 Aug 2003, Mathieu Roy wrote: <...> > But now we're discussing about it and I express my opinion: since these > packages in their postinst script install non-free stuff, I think that > even if there's no non-free stuff within the packages themselves, the > result of the installation of these packages (and not their > dependancies!) is to get non-free stuff. And so, it leads me to the > conclusion that, whatever the fact that the non-free part is downloaded > at the same time than the debian package or not, this package itself > contains non-free stuff. When your conclusion is at odds with reality you should rethink your argument... if Debian was to start classifying packages based on the probable or possible results of using the package, instead of the code in the package itself, contrib would disappear and a case could be made to place all editors in non-free because they can be used to create non-free stuff. - Bruce
Re: "non-free" software included in contrib
On Mon, 1 Sep 2003, Cameron Patrick wrote: > On Mon, Sep 01, 2003 at 09:47:46AM +1000, Matthew Palmer wrote: > > | > When your conclusion is at odds with reality you should rethink your > | > argument... if Debian was to start classifying packages based on > | > the probable or possible results of using the package, instead of > | > the code in the package itself, contrib would disappear and a case > | > could be made to place all editors in non-free because they can be > | > used to create non-free stuff. > | > | Ah, reductio ad absurdum. Such a wonderful means of demonstrating that you > | can't think up a decent argument, so you'll take something to it's illogical > | extreme to try and scare some people. > > Don't attack reductio ad absurdum, attack the utter non-sequiturs in the > original post. If a package's postinst or main goal is to fetch some > non-free piece of software, that is by no means the "probable or > possible" results of using the package, it is the only useful result of > using the package as it is intended to be used. A piece of software > designed /only/ to fetch and install some non-free software is > significantly different to the case of e.g. an editor which can be used > to write non-free software or a generalised software installer (like > dpkg) which can potentially be used to install non-free software. Exactly. What if a generalised DFSG-free software installer used a separate config file to download, debianize (using dh_make templates), then install the resulting package (most of it non-free because such a scheme should not be necessary for free stuff)... imo, the installer would go in main and the config/templates would go into contrib or non-free. Should installers be forced into non-free just because they haven't progressed to the point of being generalised yet? - Bruce
Re: installer for non-free packages in contrib
On Mon, 8 Sep 2003, Colin Watson wrote: > OK. How does one create an installer package which correctly does the > following: > > * creates a Debian package for the thing it's installing the installer contains a diff and dsc, downloads the orig source, then builds a .deb > * installs that package in such a way that it's registered in dpkg's > database do the install in the background when the dpkg DB area is unlocked > * doesn't rely on internal implementation details of dpkg such as > /var/lib/dpkg/status and /var/lib/dpkg/info/*.list files should not be an issue given the above > * when the installer package is considered by dpkg as fully > configured, the package it's installing is also fully configured > > * if some error happens when installing the created package, the > installer package will throw an error during configuration I don't think these last two are possible without a dpkg daemon (install from a queue instead of a list on the commandline), and even then it would be necessary to be able to flag a package as using a multi-stage install. For the sake of argument lets assume the installer is configured and didn't generate an error as long as it can get as far as downloading the original source: you would not be able to configure anything (during the same dpkg run) which depends on the package created by the installer, and it would not be proper to flag the installer as providing the package it creates (because the last two points can not be met)... > ? I think that's a minimal specification for a correct installer package > which does its work by creating Debian packages; unless you think that > it's better for the installer package to spit out a .deb somewhere which > you then have to install separately, which seems to me like a step > backwards in convenience. ...I guess I'd end up with a fetch-build-install instead of a proper installer package --- a (half?) step backwards with respect to Debian's dependency handling, but a step forward if the main objective is to have "installer" installed stuff managed by the package handling system. It would be clear that stuff installed by such a system is not a part of Debian (because of the lack of dependency handling), and migration into Debian would be easy when the license (or whatever is keeping the software out of Debian) changes. - Bruce
Re: Icons and instructions for the FreeDesktop menu.
On Sun January 21 2007 02:24, Steve Langasek wrote:
> On Wed, Jan 17, 2007 at 09:22:57AM +0100, Loïc Minier wrote:
> > On Wed, Jan 17, 2007, Charles Plessy wrote:
> > > am I wrong or one can have foo.png in foo.desktop, and foo.xpm in
> > > foo.menu? If upstream does not provide an xpm icon, the "convert"
> > > command of the imagemagick package can easily create one at build
> > > time.
> >
> > My point is that I shouldn't have to maintain both, or to run
> > convert each time this is necessary.
>
> While it would be good to have infrastructure to support automatic
> down-converting to the Debian menu standard where appropriate, you
> can probably see that converting, say, a 64x64 png to a 32x32 xpm is
> going to give inferior results than if an icon is provided that was
> created for the target resolution; so having menu itself
> automatically import .desktop files at runtime doesn't sound like a
> good idea to me.
If by "runtime" you mean when a user logs in or accesses a menu
hierarchy, that would likely result in annoying performance issues for
slower boxes which would be worse than any potential icon quality
problems. Icon quality is a bit of a red herring anyways, imo; as long
as those 16x16 blobs of colours are distinct from each other they serve
their purpose, and don't most icon using desktops automatically scale
icons if necessary.
I also agree that automatic down-converting would be good, but think
that automatic generation of menus from pieces at package install time
would be better. Iow, build a .menu.common for every interactive
program and use .menu.[freedesktop|kde|gnome|some-de] for Desktop
Environment specific bits, then require the menu producers be able to
construct a menu entry from the pieces via infrastructure provided
routines.
Assuming the existing menu infrastructure is working OK and the code is
in reasonably good shape, adding support for
{/usr/share,~,etc}/menu/{freedesktop,gnome,kde,some-de} should be a
straightforward extension of how the standard menus are currently
handled.
- Bruce
Re: Icons and instructions for the FreeDesktop menu.
On Sun January 21 2007 16:29, Charles Plessy wrote: > Le Sun, Jan 21, 2007 at 06:04:09AM -0700, Bruce Sass a écrit : > > I also agree that automatic down-converting would be good, but > > think that automatic generation of menus from pieces at package > > install time would be better. Iow, build a .menu.common for > > every interactive program and use > > .menu.[freedesktop|kde|gnome|some-de] for Desktop Environment > > specific bits, then require the menu producers be able to construct > > a menu entry from the pieces via infrastructure provided routines. > > As the .desktop format becomes a de facto standard, we are more and > more in a situation where the .menu files have to be written from a > .desktop file. In a system where the .desktop files used in Debian > would be generated from the Debian .menu file, this would lead to a > double conversion. Requiring the ability to produce a menu entry from pieces is not the same as requiring that all entries be produced from pieces. Conversion is not necessary if the infrastructure allows a DE to ignore all but the .menu.DE bit for apps saying they have a native menu for that DE. Simply being able to flag a .menu.DE bit as being "complete" would probably work, but it may be more flexible if it was possible for an app to indicate to a DE's menu producer which bits it needs to piece together. > If persons are willing to work on improving the Debian menu system, I > would rather advocate using the .desktop format as a native > configuration file. This way we could take advantage of existing > information, and also contribute back our work to the the upstream > developpers when a menu entry is created from scratch for Debian. I have no problem with the .desktop format. The freedesktop standard can not be expected to accommodate non-freedesktop based systems though. - Bruce
Re: Using standardized SI prefixes
On Tue June 12 2007 01:20:30 am Josselin Mouette wrote: > > "kilo" in "kilobyte" is not an SI prefix. It is not even a prefix. > "Kilo" is always a SI prefix. In computing the "K" stands for "kilobyte", not "kilo" + "byte", and a kilobyte has always been the number of memory locations addressable by the A0-A9 bits on the address bus of a bytewide system... that's 1024 possible addresses, not 1000. IOW, it is not just shorthand for an enumeration (as the SI prefixes are) or a mathematical constant, it is the name of a physical constant. "Kilobytes" naturally became the measure of capacity, (sadly) it may also be natural that Marketing twisted its ambiguity with the SI prefix in an attempt to get marketshare. "1024" will go away when we stop using binary computers. :) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue June 12 2007 02:25:59 pm Gustavo Franco wrote: > That's the point, you would be using testing for development and > cherry picking changes from unstable manually. Remember that in this > scenario we still have unstable to testing transition so if you don't > push stuff manually it will get there anyway, probably the second > step would fine tune the unstable to testing metric but RM team > already has some ideas on this camp as Luk pointed out. Hmm, Testing came about as a permanent archive so that developers could continue to work on new stuff during the long pre-release freeze[1]. For some reason they choose to make Testing permanent and devise an automatic transfer scheme rather than expand use of the existing Experimental archive (which is what your scheme is effectively doing). Why did they make that choice, and what has changed which warrants choosing differently today? - Bruce [1] that Testing can also be used to track how the next release is shaping up was more of a side-benefit than prime motivation; and it should not be surprising that most developers run Unstable because historically Testing only became relevent just prior to a release -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Sun July 15 2007 07:19:45 am Josselin Mouette wrote: > Le dimanche 15 juillet 2007 à 14:11 +0100, Neil Williams a écrit : > > Why not drop the Debian Menu Policy completely? The only sane > > argument against .desktop is hierarchy support but then the most > > pertinent complaint against menu is that the hierarchy is wasteful. > > The Freedesktop menu has hierarchy support, but it's much more clever > than the Debian menu's. > > The most important argument against it is more about window manager > coverage. There are a good number of packages with Debian menu > support and no Freedesktop menu support. Neil, If by "drop the Debian Menu Policy completely" you mean adopting Freedesktop's .desktop file format, menu hierarchy rules, and whatever tools they have for working with menus---sure. From an enduser's perspective it doesn't matter what lies beneath the menus we see[1], if you DD's decide the Freedesktop way is the better one for packaging menu entries then so be it. If you are suggesting dropping the Debian menu infrastructure as well, therebye forcing the other window managers to learn how to read .desktop files or convert them into their native format on their own time---that sounds like a bad idea. I would hate it if my lightweight and fast wm suddenly started using more RAM, took longer to startup, or if the menus became as sluggish as KDE's[2]. Since the conversion route is likely to be a popular solution and lengthening startup time is the least objectionable (both could be done without touching the wm's code), there would be a significant amount of code duplication happening and therefore pressure to devise infrastructure which does a good chunk of what the existing menu system does now. AFAICT, all potential benefits from this last kind of change favour the few window managers which natively "speak" .desktop, and everyone else gets the undoubtedly shitty end of the stick. Furthermore, it seems really odd to potentially shift onto, or create work for, all the lighter weight window managers, likely to be running on less capable than average boxes, for the benefit of window managers which pretty much require a box of average or better capabilities. IOW, if there are hoops to be jumped through to get a better menu subsystem then it is best to put those hoops into the arenas most likely to have enough spare resources to do the jumping. I would think that would be enough to place the idea of dropping the menu infrastructure in the non-starter category, but obviously it isn't because "window manager coverage" is an issue. I mean, if simply changing the menu infrastructure to use .desktop files as input is what is on the table, then presumably all window managers will need to change the way they do things and any "coverage" problems will be temporary ones which could affect any wm while the Maintainers rewrite their menu generating code. Josselin, If I am understanding you correctly then I must say that "window manager coverage" is more than just "the most important argument against", it's a TKO for the idea (see above for why I believe that). I believe I am understanding you correctly because, "Debian menu support and no Freedesktop menu support", is only an issue if the common menu generating infrastructure disappears and all we are left with is a collection of .desktop files. I hope you reconsider your position. - Bruce [1] It would be nice to have a friendly Debian->Freedesktop menu entry conversion utility so those of us with custom menu entries and no .desktop experience can get a little hand holding while we make the switch. [2] it has been awhile since I used Gnome but their menus used to be slower than KDE's, KDE's have gotten slower (and take up more HDD space, perhaps a consequence of the Freedesktop related stuff added to the menu subsystem and maybe why there has been a push to swith to .desktop files)... but the menus I get with UWM are always very fast
Re: adding desktop files to misc packages
On Mon July 16 2007 12:03:17 pm Neil Williams wrote: > On Sun, 15 Jul 2007 18:16:49 -0600 > Bruce Sass <[EMAIL PROTECTED]> wrote: > I like Don's idea - remove the Debian menu from those window managers > etc. that understand .desktop files and make the Debian menu aware > of .desktop files for those other systems. Ya, I think Don has come up with a pretty good summary of the most reasonable/significant ideas. The only thing missing is an explicit acknowledgement of the need for a way to grossly customize the menus independently of any tools provided by a specific environment. E.g., I would like the KDE K-menu to default to having a Debian submenu containing all executables, with all other submenus containing only KDE programs; if I fire up Gnome I would like its main menu to do the same; etc.---without having to independently configure each environment. > > [2] it has been awhile since I used Gnome but their menus used to > > be slower than KDE's, KDE's have gotten slower (and take up more > > HDD space, perhaps a consequence of the Freedesktop related stuff > > added to the menu subsystem and maybe why there has been a push to > > swith to .desktop files)... but the menus I get with UWM are always > > very fast > > Depends what else has been happening on the machine - the .desktop > based menus load very quickly if there is sufficient cache. The first > time I view either menu, I get the same delay on this amd64 box, it > appears to be the icons that are the cause of the delay, not the > source of the textual data. I'm not sure what is happening, only that shortly after it became annoying I noticed "xdg" related menu-methods and a ~/.local dir which hadn't existed before. It does only happen first time accessing a menu, and seems to be related more to the number of entries than whether they have icons or not. Anything I use frequently has a desktop shortcut, panel icon, or is in the quick launcher, so it's not a big deal. A combination of KDE style menu infrastructure and a less featureful environment would be very annoying though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Wed July 25 2007 10:57:54 am Josselin Mouette wrote: > If the users installs the distribution with default settings or > starts a session on a multi-user setup, he should find a usable menu, > not a menu with all possible applications he never wanted to install. Well, if there is stuff he never wanted to install then his first clue they are cluttering up his system will be their appearance in the menus. It also gives him an opportunity to easily fire them up to see what the ones he's never heard of are so he can decide if they should be purged or kept. If they are not in the menus then he either tracks them down manually and starts them from the commandline, or notices them if he pays close enough attention to upgrades. I think you've hit on a good reason to default to including everything in the menus. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Thu July 26 2007 01:02:57 am Frank Küster wrote: > Josselin Mouette <[EMAIL PROTECTED]> wrote: > > If an application is used so infrequently, it shouldn't have its > > place in a menu. > > It seems we have a very different notion of what a menu is. To me, > the reply "Exactly because it is used infrequently it should have its > place" is obvious and follows strictly from my understanding of a > menu, I don't even need an argument for that. To you, it seems to be > the contrary. I'm with Frank; what Josselin said only makes sense to me if s/menu/panel or quicklauncher/ > > This is also my usage scheme: everyday apps in the session, less > > frequently used apps in the menu, rarely used apps in a terminal or > > a launching tool. > > I don't make this distinction between "less used" and "rarely used", > and I'm not even sure what a launching tool is. I nearly never start > a graphical application from the terminal, and I don't need to be > able to start terminal applications from the menu: For me that is the > only reason for deciding whether something should have a (possibly > hidden) menu entry. I don't think there is any clear dividing line between graphical and terminal based apps as far as menus go. I routinely use text based apps in a windowed environment and if they didn't have a menu entry I would make one because having to open up a term and type in a command or start pdmenu is kinda silly when there is a menu system a click away. The only thing I'm getting outta this round of the discussion is that anything less than complete flexibility with respect to which items get placed in whatever menus would be a mistake. I.e., code the thing up so that it is easy to tell it how to build menus instead of writing it to conform to any particular idea of how menus are used. - Bruce
Re: Installation of Recommends by default on October 1st
On Wed August 8 2007 10:01:40 am Daniel Burrows wrote: > Just to clarify, aptitude didn't "come up" with anything. This was > the standard behavior in Debian at the time (dselect was far more > draconian about forcing you to install recommended packages), and one > of the top complaints I got was that aptitude mishandled Recommends > by not installing them! dselect doesn't force you to install recommended packages; for as long as I can remember (since Bo) it has given you a list with the recommends preselected, and a simple keypress is all that is needed to decline them. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Thu August 9 2007 12:08:05 pm Florent Rougon wrote: > Bruce Sass <[EMAIL PROTECTED]> wrote: > > dselect doesn't force you to install recommended packages; for as > > long as I can remember (since Bo) it has given you a list with the > > recommends preselected, and a simple keypress is all that is needed > > to decline them. > > I'm afraid your memory is not serving you well here. I've been using > Debian since the time where slink was in "frozen" state, and I > remember very well that I had to wait a few years before being able > not to install Recommends. Looking at the changelog, it seems the > change (in dpkg trunk, not in stable releases!) dates from November > 1999: > > Sun Nov 28 21:56:32 CET 1999 Wichert Akkerman <[EMAIL PROTECTED]> > > * dselect/pkgdepcon.cc: don't treat recommends like (pre-)depends. > Instead make it similar to suggests but default to selecting the > package. > > For the sake of History, ;-) I guess my memory doesn't really go back as far as I thought. Thanks for the correction. :) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
On Mon August 27 2007 04:05:24 pm Pierre Habouzit wrote: > And > it's no way we will accept the statically linked version in Debian. Why is that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
On Mon August 27 2007 05:33:05 pm Romain Beauxis wrote: > Le Tuesday 28 August 2007 00:17:40 Bruce Sass, vous avez écrit : > > On Mon August 27 2007 04:05:24 pm Pierre Habouzit wrote: > > > And > > > it's no way we will accept the statically linked version in > > > Debian. > > > > Why is that? > > Quoting [1]: > External libraries <...> Of course, obviously---for software where there is a choice, but for software which can not be built from source because it is closed or not redistributable once modified (which seems to be the case with Opera), putting a statically linked version into the archive sounds like the correct solution. btw, I agree with Russ Allbery: "...but just dropping the vendor's Debian package in our archive seems like entirely pointless..." - Bruce
Re: Why no Opera?
On Thu August 30 2007 09:52:13 am Roberto C. Sánchez wrote: > On Thu, Aug 30, 2007 at 04:47:59PM +0100, Jon Dowland wrote: > > On Mon, Aug 27, 2007 at 10:46:47PM -0600, Bruce Sass wrote: > > > Of course, obviously---for software where there is a choice, but > > > for software which can not be built from source because it is > > > closed or not redistributable once modified (which seems to be > > > the case with Opera), putting a statically linked version into > > > the archive sounds like the correct solution. > > > > and there's precedent with the netscape communicator packages from > > the pre-mozilla days. These were statically linked against several > > things afaik, motif iirc. > > Yes, but even though it was done in the past, why on earth should it > be done today? Back then, there were no alternatives. Today there > are many. With Opera it is not necessary because they provide an apt-gettable archive. The availability of alternatives isn't always good enough though. In the case of web browsers, a web designer may want to have all of them installed so they can check their work with more than just Free software. If someone is willing to make and maintain an installer package for a statically linked non-free binary, simply being statically linked shouldn't be a good enough reason to keep it out of packages.debian.org. [which is how I read the original statement I responded to] - Bruce
Re: best way to check for an active X session from a maintainer script?
On Tue September 11 2007 01:07:52 am Steve Langasek wrote: > Does anyone know of a case where this would give the wrong result? > I'm not sure what an xdmcp login would look like here, for instance, > or if startx creates a utmp entry that I should be concerned about > registering as a false positive. Running "who" from a `startx startkde' (issued on tty1) session, also logged in via XDMCP from smokie, and via KDM... [EMAIL PROTECTED]:~$ who bsasstty1 Sep 11 03:05 bsasssmokie:0 Sep 11 03:14 (smokie) bsass:0 Sep 11 03:16 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
May as well add Opera to the list... On Tue September 11 2007 11:52:36 am Anthony Towns wrote: > nameinst vote old recent no-files > iceweasel 41897 22448 6839 1260010 > epiphany-browser 32506 11395 7614 13493 4 > w3m53921 6902 30282 16735 2 > konqueror 15175 5983 5437 3754 1 > lynx 14852 5558 7840 1451 3 > iceape-browser 4802 1974 1706 1122 0 opera 3184 1876 855 450 3 > dillo 1810 519 1015 275 1 > w3m-img 721 0 0 0 721 Opera ranked 27 (behind mostly multimedia stuff) at http://popcon.debian.org/unknown/by_inst -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: start-stop-daemon --exec is incorrect on unionfs systems
On Wed September 19 2007 12:49:54 pm Tzafrir Cohen wrote: > Let's look at exim4 on such a system. The init.d script seems to > misbehave: <...> I started running into this (afaict) last fall (see bugs #396944, #440657). > What can be done about this? > > 1. Avoid using --exec . Probably risking some false kills. > 2. Ignore the problem, and leave squashfs systems broken. > > Any other way out? maybe this will help... - On Wed, Sep 05, 2007 at 04:08:38AM -0600, Bruce Sass wrote: > On Mon September 3 2007 07:47:23 am you [Marc Haber] wrote: > > I have adapted the init script to use the lsb-base functions, which > > has somewhat simplified the init script. I have not yet given it > > much testing, but you can pull it from svn. > > OK > > So, "svn-inject ...pkg-exim4/exim/trunk", then use svn-buildpackage? > [since I don't already have a Debian-SVN repository] You only want one file from svn, and that one's a conffile in the package, so you can simply svn cat svn://svn.debian.org/svn/pkg-exim4/exim/trunk/debian/exim4-base.exim4.init - Note: exim4-base.exim4.init lives on the system as /etc/init.d/exim4 - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal regarding future packaging
On Wed September 19 2007 04:53:10 pm John Goerzen wrote: > On Wednesday 19 September 2007 5:43:03 pm David Given wrote: > > John H. Robinson, IV wrote: > > [...] > > > > > I like this idea, especially if there were a short description > > > about each program and relevent configuration files. > > > > I like this too. Finding what a package has just installed is one > > of the biggest holes in Debian right now, IMO. I have to use dpkg > > -L to figure this out, and that's just too crude to be a real > > solution. > > Too crude? That's a simple command, easily found in a relevant > manpage. In true Unix fashion, its output can be easily piped to > other commands. What's crude about it? It doesn't catch files created by Maintainer scripts? I'm hoping the dpkg "triggers" functionality Ian Jackson has been working on will help solve that wart though. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal regarding future packaging
On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote: > 19-09-2007, Bruce Sass: > > I'm hoping the dpkg "triggers" functionality Ian Jackson has been > > working on will help solve that wart though. > > How exactly? Exactly? I don't know. I haven't followed what is happening close enough. Basically, it allows a package to toss up a flag saying, `I'm here and needs to be done.' It may require some convention and a little more infrastructure, but that is close to letting a package say, `add these paths to the list of paths which I control.' - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal regarding future packaging
On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote: > 21-09-2007, Bruce Sass: > > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote: > >> 19-09-2007, Bruce Sass: > >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has > >> > been working on will help solve that wart though. > >> > >> How exactly? > > > > Exactly? I don't know. I haven't followed what is happening close > > enough. > > > > Basically, it allows a package to toss up a flag saying, `I'm here > > and needs to be done.' It may require some convention > > and a little more infrastructure, but that is close to letting a > > package say, `add these paths to the list of paths which I > > control.' > > Sure. But i thought, we are talking about finding/listing of > generated files. It is not feasible (imo) to automatically find files created by maintainer scripts. Having packages append .list themselves would (afaict) require they know too much about dpkg's internal operation, and all packages generating files would need to implement the algorithm. However, maintainer scripts can easily pass a list of generated paths on to a shared piece of code which dpkg controls. "triggers" looks like it could be the mechanism by which a package flags that it has generated files, and by which dpkg exerts control. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
semi-virtual packages?
On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote: > On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > > On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote: > >> 21-09-2007, Bruce Sass: > >> > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote: > >> >> 19-09-2007, Bruce Sass: > >> >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has > >> >> > been working on will help solve that wart though. > >> >> > >> >> How exactly? > >> > > >> > Exactly? I don't know. I haven't followed what is happening > >> > close enough. > >> > > >> > Basically, it allows a package to toss up a flag saying, `I'm > >> > here and needs to be done.' It may require some > >> > convention and a little more infrastructure, but that is close > >> > to letting a package say, `add these paths to the list of paths > >> > which I control.' > >> > >> Sure. But i thought, we are talking about finding/listing of > >> generated files. > > > > It is not feasible (imo) to automatically find files created by > > maintainer scripts. Having packages append .list > > themselves would (afaict) require they know too much about dpkg's > > internal operation, and all packages generating files would need to > > implement the algorithm. > > > > However, maintainer scripts can easily pass a list of generated > > paths on to a shared piece of code which dpkg controls. "triggers" > > looks like it could be the mechanism by which a package flags that > > it has generated files, and by which dpkg exerts control. > > But this does not address the case of a file shared by many > packages but really owned by none. True, but... Since such a file is owned by none, it can not be owned by anyone. The same solution would apply, if we could create a package for it on the fly. Is there any situation where ownership has collided, and a virtual package is/(could) not (be) Provide:-ed? [Realizing that discussion about wild ideas is far from sublime, I decided to put some thoughts to rhyme, hope it works this time.] [assuming a, "no", to the above... ya, both question and poetry :D ] Perhaps virtual packages need to have a real presence on the system when such a situation exists. If you are willing to go for that, and assuming dpkg triggers can be used for this kind of thing: A package generating a file which is most properly owned by a virtual package it Provides: could trigger, `add these paths to the list of paths owned by .' Same game as above, different package name. - dpkg (controlled code) would need to create an entry in the DB (i.e., status, info/*, ...) for these semi-virtual packages, and remove/purge them when the last package providing a virtual package is removed/purged. - Since these semi-virtual packages would only exist if a real package was providing them there should be no problem with respect to dependency calculations if they actually exist in the DB. - I suspect a new Provided-by: field in the DB could help dpkg keep track of what's up during failed upgrades, and if not, the frontend tools would probably like to be able to convey the info onto users. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote: > On Sun, 23 Sep 2007 04:13:41 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > > On Sat September 22 2007 10:21:43 pm Manoj Srivastava wrote: > >> On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > >> > On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote: > >> > > >> > It is not feasible (imo) to automatically find files created by > >> > maintainer scripts. Having packages append .list > >> > themselves would (afaict) require they know too much about > >> > dpkg's internal operation, and all packages generating files > >> > would need to implement the algorithm. > >> > > >> > However, maintainer scripts can easily pass a list of generated > >> > paths on to a shared piece of code which dpkg controls. > >> > "triggers" looks like it could be the mechanism by which a > >> > package flags that it has generated files, and by which dpkg > >> > exerts control. > >> > >> But this does not address the case of a file shared by many > >> packages but really owned by none. > > > > True, but... Since such a file is owned by none, it can not be > > owned by anyone. The same solution would apply, if we could create > > a package for it on the fly. > > We can create any number of dummy packages on the fly, but > what is the use case we are trying to solve here? Why are we adding a > virtual package, having package provide the virtual package, given > that this virtual package does not provide any functionality, and so > no other package is going to depend on it? Why are you asking that. You provided the use case---"a file shared by many packages but really owned by none." I have written nothing about "adding a virtual package", and the functionality of the existing virtual packages which I would manifest is obvious---provide a home for the files "shared by many packages but really owned by none." > > Perhaps virtual packages need to have a real presence on the system > > when such a situation exists. > > > > If you are willing to go for that, > > I might be willing to go for that if there was a clear > statement of benefit gained, what use case we are satisfying, and if > there were convincing arguments that other solutions are not a better > fit than trying to shoe horn dpkg -L to be the solution to whatever > use case we are attempting to solve (this is no longer the original > use case presented -- I-do-not-know-where-the-documentation-is). Huh. You provided the case, and the benefit should be obvious---and if it is not then why did you bring up addressing, "the case of a file shared by many packages but really owned by none"? WTF does "shoe horn dpkg -L" have to do with what I wrote? That sounds a lot like the wedging we used to do back in the early 80's when the OS was in ROM and it wasn't practical to rewrite it. I would hope Debian can do better than such hacks. Ya, this is different from "I-do-not-know-where-the-documentation-is", but then that should not be surprising since I'm not addressing that. I did not even realize that is what the thread's originator was asking until he clarified by answering someone who appears to have had the same misunderstanding as I about what he was asking. > So, can we start over, and have a clear problem statement, > alternate solutions (does this move into tripwire space?), and then > decide what the preferred solution is? "tripwire", again, WTF. What I mentioned no more moves into "tripwire space" than installing or upgrading any other package does. So, it would be handled by whatever mechanism currently does that. Surely you don't think the OS should cater to whatever deficiencies some app running on it has. I don't see any need for myself to start over. I answered Oleg's question, and addressed your case. You, on the other hand: seem to have forgotten what you wrote; failed to answer the one question I asked; and brought up irrelevant stuff like, "shoe horn dpkg -L", and "tripwire space." I think you need to start over. Ya know, I thought that if I was really very lucky there was an outside chance of getting a, `posts on -devel rarely make me smile, but yours seems to have walked that mile', but if you really want to be pissy and obtuse... I can do that too. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote: > On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > > On Sun September 23 2007 11:00:58 am Manoj Srivastava wrote: > >> We can create any number of dummy packages on the fly, but what is > >> the use case we are trying to solve here? Why are we adding a > >> virtual package, having package provide the virtual package, given > >> that this virtual package does not provide any functionality, and > >> so no other package is going to depend on it? > > > > Why are you asking that. You provided the use case---"a file shared > > by many packages but really owned by none." > > Yup, I provided that use case. I see no reason to create a > virtual package to implement the use case I provided. > > I ask again, do you have a use case which led you down the > path of proposing a virtual package? I say again, I have not proposed creating any virtual packages... > > I have written nothing about "adding a virtual package", and the > > functionality of the existing virtual packages which I would > > manifest is obvious---provide a home for the files "shared by many > > packages but really owned by none." ...what I did mention was: > >> > Perhaps virtual packages need to have a real presence on the > >> > system when such a situation exists. I ask again, with slightly different words: Is there any "case of a file shared by many packages but really owned by none" which does not already have a virtual package associated with it? Unfortunately, "I see no reason to create a virtual package to implement the use case I provided.", sounds like a "yes" but it doesn't really answer the question. I can't find a case so I can not demonstrate something which doesn't exist, you think you've found a case so you should be able to describe it more fully than "I see no reason". Everything I described after that point was under: assuming a, "no". If you would have answered "yes" to that question then you should have ignored (at least from the perspective of solving the case you mentioned) everything after that point because it was clearly not applicable to your use case. It would have then been a good idea to describe why your use case results in a "yes" because I was, equally clearly, not able to think of a situation including your use case which should not already involve a virtual package. If it was otherwise I would not have assumed "no", ya. > >> > If you are willing to go for that, > >> > >> I might be willing to go for that if there was a clear statement > >> of benefit gained, what use case we are satisfying, and if there > >> were convincing arguments that other solutions are not a better > >> fit than trying to shoe horn dpkg -L to be the solution to > >> whatever use case we are attempting to solve (this is no longer > >> the original use case presented -- > >> I-do-not-know-where-the-documentation-is). > > > > Huh. You provided the case, and the benefit should be obvious---and > > if it is not then why did you bring up addressing, "the case of a > > file shared by many packages but really owned by none"? > > No, my use case merely says that we should be able to have a > situation where we have a configuration file that does not belong to > a package. And yes, I see the benefits of this use case immediately. it is stuff like this which tends to act like `pee in my cornflakes' What does the "No" you wrote connect with: - the fact that you provided the use case, in spite of your, "Yup, I provided that use case.", statement - the implication that benefits should be obvious to you, since you provided the case - is it an answer to the question itself, even though the answer should be in the form of an explanation - is it a denial of your own words, which I quoted verbatim - a claim that I've twisted the meaning of the quote somehow, even though the only thing missing is: "But this does not address..." ? OK. So you should be pleased I have not said anything which would take that possibility away, or force an action from abstainers. If a Maintainer script wants to create an orphan file it would simply neglect to trigger after creating it. > > WTF does "shoe horn dpkg -L" have to do with what I wrote? That > > sounds a lot like the wedging we used to do back in the early 80's > > when the OS was in ROM and it wasn't practical to rewrite it. I > > would hope Debian can do better than such hacks. > >
Re: semi-virtual packages?
On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote: > On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > > On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote: > >> On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <[EMAIL PROTECTED]> said: [I've cut a lot of duplication. If I cut something which doesn't get addressed below, feel free to bring it back.] > > The scheme I described was under the written assumption there > > are no such situations which would not already have a virtual > > package. > > Ah. That assumption turns out to be incorrect. Haha. There is nothing wrong with the assumption. That is kinda like saying pylint is incorrect for spitting out errors when given a correct perl program. You ignored a sign which would have taken you down a different path, and now appear to be complaining because the path you ended up on took you to the wrong place---neither the sign or paths are incorrect, you just didn't pay attention and got lost. > > Why would you think any of that scheme was applicable to the case > > you were thinking of if it is a case in which there is no virtual > > package? > > I am not sure how to answer that. I assumed that the scheme > under discussion was going to be universal (or else it does not seem > to be much good, really -- it would still leave files around that are > not associated with anything). I don't see why it would need to be universal, "one size" stuff often doesn't fit anyone very well and it is not like being universal is pervasive and this would stand out as a wart. I think I see where you are getting confused though. On the one hand you seem to be saying there are files that should be orphans (e.g.: /etc/kernel-img.conf), yet you criticize the scheme for not being universal. Why does not being universal "not seem to be much good" if you actually don't want universality because you know of files which shouldn't or can't be owned by a package? You did the same sorta thing earlier. Your initial post seemed to be *faulting* a scheme to append paths to .list for not addressing "the case of a file shared by many packages but really owned by none", yet later on you state: "my use case merely says that we should be able to have a situation where we have a configuration file that does not belong to a package". Why should a scheme to add files generated by a package to its own .list need to address the case of files without packages that don't want to be owned? The way I see it, from a logical pov, you can resolve the contradictions by giving up the premise of universality. Once you do that, the opt-in nature of the mechanism takes care of /etc/kernel-img.conf and like, trivially (nothing more trivial than doing nothing, eh). > What use case _is_ "knowing what package a file belongs to" a part of? "dpkg -S" (and any programs which use it) , cruft, idle curiosity, ... > >> Now, I suppose you are only worried about files in /etc and sch; > >> and not files under /var (no way to associate a lot of those files > >> with the packages that contain the entities that created them). > > > > I wasn't worried at all about where the files created by Maintainer > > scripts would reside, just that they were being created and there > > was a virtual package which could be given a real presence to claim > > ownership of them via info/.list. > > And in case there is no virtual package? status quo > > I had considered that files under /etc which are owned by a > > semi-virtual package may need special handling, but could not think > > of a case for which simply not-purging the previous version before > > upgrading to the next wouldn't be an adequate solution. Since that > > is how dpkg currently behaves I saw no need to bring it up. The > > same would apply to files under (say) /usr/share/doc/ > package>. > > Ah. This is not anything I was talking to. I knew that. It is just more info which may help resolve the problems. > But I see the problem: if anything were to depend on a > changed format of /etc/kernel-img.conf; there would be no pre-defined > way to manage that. No matter what you purge, that file does not go > away. [ignoring that kernel-img.conf doesn't have to opt-in, so handling that situation could be as it is now] Uhm, that is only a problem if a file is not owned by a package. This thread has been about a mechanism which could add such orphan files to a package so they can be listed, search for, removed, purged, or whatever else one (admin or program) does with that relationship. Maybe this wasn't as clear as I thought:
Re: semi-virtual packages?
On Thu September 27 2007 01:33:21 am Manoj Srivastava wrote: > On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > Hmm? You assumed, and I quote "there are no such situations > which would not already have a virtual package". Since there are > situations where there is no virtual package, it certainly seems to > me that the assumption you made is invalid. That is not correct, what I assumed was: a, "no", to the above [question] What you quoted is not a primary assumption (as you've been treating it as), it is based on a condition having been met. > If your assumption is correct, then I have missed something > somewhere. The bit you're still missing is the first part of the question you didn't answer: "Is there any situation where ownership has collided" IOW: if the file shared by many packages isn't having ownership problems there is no need to consider it (no point trying to fix something that is not broken, eh). > > I don't see why it would need to be universal, "one size" stuff > > often doesn't fit anyone very well and it is not like being > > universal is pervasive and this would stand out as a wart. > > If we are not talking about a policy to be made, and you are > only talking about an opt in scheme for some orphan files, then > indeed, I have nothing to add to the conversation. s/some/all but a few/I suspect - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Thu September 27 2007 05:38:53 pm Manoj Srivastava wrote: > On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > > The bit you're still missing is the first part of the question you > > didn't answer: "Is there any situation where ownership has > > collided" > > > > IOW: if the file shared by many packages isn't having ownership > > problems there is no need to consider it (no point trying to fix > > something that is not broken, eh). > > The start of this thread was a rant about not loose files > floating around in /etc; not necessarily about whether these files > in themselves had ownership problems (whtever that means). > > Here is the original context. Note how you say the problem > (actually, design flaw) is about current tools do not "catch files > created by Maintainer scripts"? > > Nice to see the design flaw has become stuff that is not > broken and does not have to be fixed. That is all I cared about, > really. Oleg considers it a design flaw, I have stated no such opinion and didn't even include his statement to that effect in my reply. Why would you bring it up... grasping at straws, perhaps. The original context I was responding to, and which you jumped in on, is this: - On Sat, 22 Sep 2007 03:46:26 -0600, Bruce Sass <[EMAIL PROTECTED]> said: > On Sat September 22 2007 12:16:18 am Oleg Verych (Gmane) wrote: >> 21-09-2007, Bruce Sass: >> > On Thu September 20 2007 09:25:23 pm Oleg Verych (Gmane) wrote: >> >> 19-09-2007, Bruce Sass: >> >> > I'm hoping the dpkg "triggers" functionality Ian Jackson has >> >> > been working on will help solve that wart though. >> >> >> >> How exactly? >> > >> > Exactly? I don't know. I haven't followed what is happening close >> > enough. >> > >> > Basically, it allows a package to toss up a flag saying, `I'm here >> > and needs to be done.' It may require some convention >> > and a little more infrastructure, but that is close to letting a >> > package say, `add these paths to the list of paths which I >> > control.' >> >> Sure. But i thought, we are talking about finding/listing of >> generated files. > It is not feasible (imo) to automatically find files created by > maintainer scripts. Having packages append .list themselves > would (afaict) require they know too much about dpkg's internal > operation, and all packages generating files would need to implement > the algorithm. > However, maintainer scripts can easily pass a list of generated paths > on to a shared piece of code which dpkg controls. "triggers" looks > like it could be the mechanism by which a package flags that it has > generated files, and by which dpkg exerts control. But this does not address the case of a file shared by many packages but really owned by none. manoj - You then proceeded to demonstrate that you: have trouble reading, following arguments, keeping track of what your own use case actually is, and using logic. You are now finishing up with misquotes and misrepresentation of anothers position. Do you wonder why you get in so many fights and pointless arguments. :-/ Bye-bye, and I wish you luck in whatever little fantasy world you've constructed for yourself. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
Someone wrote: > If you actually need to make this sort of response, could you do the > rest of us a favor and not do so publicly? Ya, you're right. Sorry. My frustration got the better of me. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
why are there /bin and /usr/bin...
/sbin and /usr/sbin, /lib and /usr/lib directories? AFAICT, the reason is so that a minimal but functional system is guaranteed to exist so long as a local HDD with a root filesystem is available (which doesn't necessarily include /usr); and that is a good thing to have because it gives developers a core set of software tools they can count on to always exist and facilitates troubleshooting or repairs if something breaks (e.g., bug# 592361, where I've worked around the problem by using /bin/nano to reconfigure the box with a static IP address). If that is a good reason, perhaps even The reason, for having both /bin and /usr/bin, etc., then doesn't it follow that all files required by executables residing in /bin and /sbin should also be available so long as a local HDD with a root filesystem is available (otherwise those executables are either broken or crippled)? I suppose there could be cases where the broken or crippled functionality is not useful or required when a properly populated /usr doesn't exist, but I expect those would be "special" cases, because, generally, crippled or broken programs are a bad thing. ya? I'm trying to understand the logic behind it not being an automatic bug (i.e., something which is a good candidate to check for at build-time) for stuff in /bin and /sbin to require stuff in /usr; and I've gotten onto this because of bugs like #592361 and #589123, and the observation that over the last couple/few years I seem to be running up against problems related to this issue more and more frequently. With bugs in scripts (e.g., #589123) it should be good enough that a text editor is available, but with broken binaries (e.g., #592361) the potential to be put in a not-so-easy-to-fix situation is pretty high (remember, dpkg is not around when /usr is missing and the fix is going to arrive in a .deb)--so maybe that one should generate a warning of some sort. I was curious so... $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then if [ "`ldd $f | grep /usr`" != "" ] ; then echo `dpkg -S $f`; ldd $f; fi; fi; done iputils-ping: /bin/ping6 linux-gate.so.1 => (0xb770d000) libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0x472dc000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0x4882b000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0x46d3d000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) /lib/ld-linux.so.2 (0x46bad000) isc-dhcp-client: /sbin/dhclient linux-gate.so.1 => (0xb770c000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0x4882b000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0x46d3d000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) /lib/ld-linux.so.2 (0x46bad000) discover: /sbin/discover linux-gate.so.1 => (0xb78f5000) libdiscover.so.2 => /usr/lib/libdiscover.so.2 (0x46d15000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x47109000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) util-linux: /sbin/fsck.cramfs linux-gate.so.1 => (0xb7893000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) util-linux: /sbin/mkfs.cramfs linux-gate.so.1 => (0xb7755000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) iptables: /sbin/nfnl_osf linux-gate.so.1 => (0xb785f000) libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x46d15000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) udisks: /sbin/umount.udisks linux-gate.so.1 => (0xb78ac000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x4b1bb000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0x46d43000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x47277000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x47027000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x4b18) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x470f8000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0x46eba000) /lib/ld-linux.so.2 (0x46bad000) libpcre.so.3 => /lib/libpcre.so.3 (0xb7856000) Are these bugs just waiting to bite, or frustrate troubleshooting efforts because some program is broken just when it is needed most? later, - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008100315.36920.bms...@shaw.ca
Re: why are there /bin and /usr/bin...
On August 10, 2010 04:18:10 am Stanislav Maslovski wrote: > On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote: > > /sbin and /usr/sbin, /lib and /usr/lib directories? > > > > AFAICT, the reason is so that a minimal but functional system is > > guaranteed to exist so long as a local HDD with a root filesystem > > is available (which doesn't necessarily include /usr); and that is > > a good thing to have because it gives developers a core set of > > software tools they can count on to always exist and facilitates > > troubleshooting or repairs if something breaks (e.g., bug# 592361, > > where I've worked around the problem by using /bin/nano to > > reconfigure the box with a static IP address). > > Not just to repair. First of all, / must have enough tools to > bring the system up to the point where the other file systems can be > mounted (i.g., over the network). Ya, I consider that to be the main use for the `core set of tools that can be counted on'. > > If that is a good reason, perhaps even The reason, for having both > > /bin and /usr/bin, etc., then doesn't it follow that all files > > required by executables residing in /bin and /sbin should also be > > available so long as a local HDD with a root filesystem is > > available (otherwise those executables are either broken or > > crippled)? > > All files that a tool requires to operate must be there, for sure. > > > I suppose there could be cases where the broken or crippled > > functionality is not useful or required when a properly populated > > /usr doesn't exist, but I expect those would be "special" cases, > > because, generally, crippled or broken programs are a bad thing. > > ya? > > Can you give examples of such special cases? Nope, it just seemed short-sighted to ignore the possibility. Simon McVittie mentioned an even better/plausible situation where some crippling wouldn't really matter... > (For instance, if /bin/vi is vim, it's OK if it can't do syntax > highlighting until /usr is mounted, as long as it can edit text.) > > I'm trying to understand the logic behind it not being an automatic > > bug (i.e., something which is a good candidate to check for at > > build-time) for stuff in /bin and /sbin to require stuff in /usr; > > and I've gotten onto this because of bugs like #592361 and #589123, > > and the observation that over the last couple/few years I seem to > > be running up against problems related to this issue more and more > > frequently. > > This is an unfortunate consequence of the fact that less and less > developers separate /, /usr, /var, etc. partitions on their machines. > In the past I always did it on my workstations, however, stopped > doing it around the time of lenny's release. Hehe... never run into a process that starts filling up the HDD, or perhaps had to use an HDD small enough that the possibility even existed. > > With bugs in scripts (e.g., #589123) it should be good enough that > > a text editor is available, but with broken binaries (e.g., > > #592361) the potential to be put in a not-so-easy-to-fix situation > > is pretty high (remember, dpkg is not around when /usr is missing > > and the fix is going to arrive in a .deb)--so maybe that one should > > generate a warning of some sort. > > Well, just the other day I was helping a user on #debian to repare > his Debian installation, using mostly sed to edit the config files. > Nano was not functional without /usr and it seemed he did not have > any other editor. Hmm, /bin/nano worked for me. It spit out a screen full of warnings about stuff from /usr it couldn't find, then asked if it should continue. I don't know what it was missing but it worked well enough to edit /etc/network/interfaces. Thanks. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008100632.03036.bms...@shaw.ca
Re: why are there /bin and /usr/bin...
On August 10, 2010 04:25:07 am Simon McVittie wrote: > On Tue, 10 Aug 2010 at 03:15:35 -0600, Bruce Sass wrote: > > AFAICT, the reason is so that a minimal but functional system is > > guaranteed to exist so long as a local HDD with a root filesystem > > is available > > The fact that you can use it for troubleshooting/repairs is a nice > (and desirable) side-effect, but the actual requirement is that you > have enough binaries, libraries etc. to mount your /usr filesystem. > The situation you have (NFS /usr) is meant to be supported, if I > understand correctly, but as you've observed, it's not heavily > tested. > > In theory, I believe NFS /var is also supported, but that's likely to > be even less well-tested. > > > If that is a good reason, perhaps even The reason, for having both > > /bin and /usr/bin, etc., then doesn't it follow that all files > > required by executables residing in /bin and /sbin should also be > > available so long as a local HDD with a root filesystem is > > available (otherwise those executables are either broken or > > crippled)? > > There need to be enough libraries in /lib for the binaries in /bin > and /sbin to run and carry out core functionality, including anything > that's normally done before /usr is mounted. Beyond that, I think > it's OK if binaries there work sub-optimally, as long as they work. > > (For instance, if /bin/vi is vim, it's OK if it can't do syntax > highlighting until /usr is mounted, as long as it can edit text.) > > It might be worth having a Lintian check for the situation you > describe, since missing libraries will generally prevent the > executable from starting up at all, whereas missing bits of > /usr/share or /var might not be so important. Ya, my thoughts exactly, it is easy to check for and provides the most potential benefit. > If you're filing bugs for this, they should be against the thing that > doesn't work (e.g. isc-dhcp-client), not the library it requires (I > see Kurt has reassigned your isc-dhcp-client bug already). I saw it as a bit of a toss up whether to file against isc-dhcp-client or the lib's package--either seemed just as likely to end up getting reassigned, and changing the location of the lib should be the quicker/easier/safer fix (regardless of whether that is the technically the most correct fix or not)... more so now that I've had a chance to look at the isc-dhcp-client source package and see that it would most likely be necessary to muck around with code itself (new code during a freeze, eh). > > iputils-ping: /bin/ping6 > > Looks likely to be a bug, but probably of 'normal' severity; it > doesn't affect most people, and you don't need ping in order to boot > (although it's a good troubleshooting tool). > > > isc-dhcp-client: /sbin/dhclient > > If you're using DHCP and NFS /usr on the same machine , you're braver > than me :-) but yes, if that's the situation you have, then the DHCP > client is in the critical path for booting. > > > discover: /sbin/discover > > It may be worth checking why discover is on the root filesystem at > all? > > > util-linux: /sbin/fsck.cramfs > > libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) > > Ubuntu has moved zlib to /lib for some other reason, > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591013 requests that > Debian do the same. > > > util-linux: /sbin/mkfs.cramfs > > libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) > > The FHS says mkfs.* have to be on the root filesystem. I'm not > entirely clear why this is. > > > iptables: /sbin/nfnl_osf > > libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 > > (0x46d15000) > > Looks like a bug, but nfnl_osf has no man page, so I have no idea > what it does or whether/why it needs to be in /sbin... lhttp://www.ioremap.net/projects/osf Presumably OS Fingerprinting based filter actions are useful early on. > > udisks: /sbin/umount.udisks > > libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 > > (0x4b1bb000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 > > (0x47277000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 > > (0x470f8000) > > This needs to be in /sbin because umount looks for > /sbin/umount.$FILESYSTEM and udisks acts like a pseudo-filesystem, > but I don't think unmounting things that were mounted with udisks in > the absence of /usr really needs to be a supported use case, so I'd > say this is 'minor' severity. Thanks. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008100842.14592.bms...@shaw.ca
Re: why are there /bin and /usr/bin...
On August 10, 2010 03:53:10 pm Goswin von Brederlow wrote: > Bruce Sass writes: > > I was curious so... > > $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; > > then if [ "`ldd $f | grep /usr`" != "" ] ; then echo `dpkg -S $f`; > > ldd $f; fi; fi; done > > iputils-ping: /bin/ping6 > > linux-gate.so.1 => (0xb770d000) > > libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 > > (0x472dc000) libcrypto.so.0.9.8 => > > /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0x4882b000) > > Note that there is /lib/libcrypt* (at least here). Yes, libcrypt (from the libc6 package) exists as a regular file under /lib and a symlink under /usr/lib... if libcrypto (from the libssl0.9.8 package) did the same dhclient wouldn't have failed on me and I wouldn't be here. :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008101631.18368.bms...@shaw.ca
Re: why are there /bin and /usr/bin...
On August 15, 2010 04:30:04 pm Perry E. Metzger wrote: > On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass wrote: > > /sbin and /usr/sbin, /lib and /usr/lib directories? > > > > AFAICT, the reason is so that a minimal but functional system is > > guaranteed to exist so long as a local HDD with a root filesystem > > is available (which doesn't necessarily include /usr); > > The true reason is that back in ancient days, hard drives were too > small to put everything in one place, so ancient Unix machines at > Bell Labs in the 1970s ended up with some programs on the root disk > and some on the same supplementary disk where the home directories > were typically put. This was not done with any great forethought, it > was simply a temporary expediency. Because / was on the boot disk, it > was necessary to make sure that every program needed for initial boot > was there, and thus some programs were more important to put in /bin > and the like. ... Thanks. I like the "onion" story, I don't think it is entirely fitting though--to gain the benefit of that dollar or so worth of HDD space I'd need to effectively re-tool to get it installed... if it was necessary to replace the vat (shutdown production, remove a wall or two, rewire the controls, etc.) to get rid of the onion I suspect they'd still be used in some older varnish plants. What I'd really like to see is support for a shared /usr hierarchy and a way to optionally push configs onto separate boxes. Such a setup would be useful in a classroom or office where it is desirable for everyone to have the same software installed and there are enough boxes that maintaining them as independent units can be expensive. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008160654.05513.bms...@shaw.ca
Re: unstable/testing/[pending/frozen/]stable
On September 22, 2010 01:35:14 am Mehdi Dogguy wrote: > On 09/22/2010 08:47 AM, Mike Hommey wrote: > > On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: > >>> Then unstable/testing would roll further as usual > >> > >> How does a major, disruptive, transition get done? > > > > I think his proposal boils down to this: we *always* have unstable > > and testing to upload whatever we want and handle transitions when > > we like. Then, parallel to unstable/testing, there would be the > > pending/frozen suites to work on the release. Saying it a bit > > differently, we would *also* already be working on release+1 while > > release is being frozen. I kind of like the idea. > > > > To give an example with package names, I would already upload > > iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse > > dependencies until they are fixed to use xulrunner 1.9.2, while > > keeping updates for iceweasel 3.5 in pending/frozen. It would also > > allow me to push iceweasel 4.0 betas to experimental, where they > > would be better suited than their current location, where they are > > not even built on non x86/x86-64. > > It means that the Release Team will have to handle transitions in > unstable, migrations to testing, as well as the ongoing freeze in > "frozen". I don't think we have enough manpower for that. And, during > a freeze, we need each one to concentrate on fixing things (while > there is still experimental to test things). If we add a > play-forever-suite, we will loose some manpower without any doubt and > it will make releases harder to acheive, imho. > > Besides, how de we merge things after a release? unstable would be > something quite different from released frozen. Some bugfixes might > have been applied only for frozen or pending, some other package will > have new versions in unstable (and their rev-deps rebuilt)… I think > it could be a nightmare to manage, imho. Unstable and Testing appear to quickly diverge from a new release's versions, becoming "something quite different from released", in a matter of days or few weeks. The only difference in this regard if a "frozen" existed would be that they could diverge sooner... wouldn't that be a headstart on the next Stable? What if packages only became "frozen" when the set of dependency relationships they are involved in is consistent (enough?) In this scenario there would be no (only minor?) transitions happening in Frozen, and consequently no (little?) need to merge dependency related bugfixes (the only "some" of consequence, afaict) into Unstable or Testing packages. Simply having that as a goal may encourage more or more prompt work on packages in Testing. I've heard that Testing cycles between good/installable and bad/un-installable--do those good times correspond to times when it would be possible to freeze a set of packages? i.e., is there already an indicator that can be used to trigger a mostly automatic action which over time would result in Frozen becoming a release candidate? anyways, here's a somewhat philosophical thought on the matter... Currently Debian can only "see" the past (Stable) and present (Unstable/Testing). Creating an always-consistent-"frozen" category of packages would let Debian "see" the past (Stable), present (Frozen), and future (Unstable/Testing). - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009221117.16849.bms...@shaw.ca
Re: nethack popularity contest - number_pad?
yes, number_pad why, because I don't need to remember what the arrows on the keys mean
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: > Andrew Suffield wrote: > > On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: > > >> You do realize that the desktop standard has more features than the > >> debian menu system? Like i18n, icon theming, dynamic construction of a > >> menu hierarchy based on user /Desktop system preferences and so on? And > >> that this information would be lost? Why not run it the other way around, > >> convert the existing debian menu entries to .desktop files and work from > >> there? I think that this way would help debian on the desktops. > > > > Because you gain *nothing* and introduce a pointless transition. > > The question to solve is: > In which format shall application packages store > their menu information. It doesn't matter, software can make anything look like anything else... the question should be, "what requires more work: adding features to the existing menu system, or changing the entire menu system." > Users and developers propose following the > freedesktop standard and using this. Users and developers are also resisting the proposal. > Freedesktop standard supporting > systems are probably used by 90% of all Debian desktop users. Unsubstantial, and probably bullshit. > Now you say: "No let's use the debian menu system, which only we use and > which is not the default of any major WM". This means losing i18n, dynamic > construction of menus and icon theming in 90 % of the desktop, because > Debian menu items do not support these features. > > How is this logical? How does the freedesktop standard not "gain" us > features? Because nobody but KDE and Gnome use those features and they already support .desktop files. > > None of which is the problem of the menu package. It just has to read > > the fields and pass them to the methods, which then write out suitable > > data files for the frontend. In the case of kde/gnome, that would be a > > .desktop file; for everything else, yes, the data is thrown > > away. Nothing else supports those features, and this is again not our > > problem. > > freedesktop entry features > debian menu file features > > Therefore you can do a lossless transition from .desktop to menu, but not > the other way around. It makes sense to use the .desktop standard. True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. > Then those desktops who support it (KDE+Gnome+??) can use the desktop files > directly. For other (older or simpler) desktops the debian menu system has > to be adapted to use the .desktop files (addditionaly or instead of the > menu files). older -> stability simpler -> faster, less resources hungry > I don't understand how anyone can not support this change. Because: Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. also There is currently no way to provide system-wide alternates to the distributed .desktop files. Only having per-user customisation available really, really, sucks, imo. and I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? - Bruce
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Tom wrote: > On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: > > freedesktop entry features > debian menu file features > > > > Therefore you can do a lossless transition from .desktop to menu, but not > > the other way around. It makes sense to use the .desktop standard. > > I know what you mean, but don't you mean "lossless transition from menu > to .desktop" ? .desktop is the one that has more features, so a > transition from .desktop to menu would lose. > > It's trivial but I might not understand the issues if its the opposite. It is a metter of perspective. A transition from .desktop to menu only loses if the subsystems using the menu entries are capable of using the lost data. HTH - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Henning Makholm wrote: > Scripsit Bruce Sass <[EMAIL PROTECTED]> > > On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: > > > > In which format shall application packages store > > > their menu information. > > > It doesn't matter, > > If you don't think the problem being discussed matters, why are you > participating in the discussion? The "problem" is real, the format used to convey the data is immaterial. > > the question should be, "what requires more work: adding features to > > the existing menu system, or changing the entire menu system." > > Is there a difference? The changes being contemplated consist in > adding features, and any addition of features constitute a change. Yes. relatively small change vs. rewriting almost from scratch > > > Users and developers propose following the > > > freedesktop standard and using this. > > > Users and developers are also resisting the proposal. > > With few or no actual arguments about what would go bad. The pain is not worth the gain... why should all the menu consumers need to redo their menu handling so two of them can have a slightly easier time of it. > > > How is this logical? How does the freedesktop standard not "gain" us > > > features? > > > Because nobody but KDE and Gnome use those features and they > > already support .desktop files. > > Yes, but that does not buy KDE and Gnome users anything unless the > .desktop files are in the .debs for the applications they use. We're > discussions how to allow the .debs to contain them without duplication > of information and needless redundancy. Ok. How about doing it so the vast majority of menu consumers are not stuck with a needless rewrite. > > > freedesktop entry features > debian menu file features > > > True, but everyone except KDE and Gnome will toss out the freedesktop > > features. Processing bloated .desktop files just to toss the > > results is a waste of resources. > > The fraction of Debian users who use KDE and Gnome is probably less > than 90%, but I don't believe that it is small enough that it makes > sense to oppose on principle their getting the information they want. All users should be able to get what they want, including those who don't want KDE or Gnome... saddling them with bloated .desktop files does not achieve that. > > Nobody benefits from the transition... not even KDE or Gnome, since > > they already support the features the freedesktop standard brings to > > the table. > > Having a .desktop infrastructure is worth nothing if you dont have the > data it works with. KDE and Gnome users would certainly benefit from > having .desktop files in the .debs of the packages they use. Yes, but they would benefit in the same way if the KDE and Gnome specific bits were an addendum to the main menu data entries. Only KDE and Gnome users stand to benefit, so they should be the ones with the added burden. > > I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce > > and mwm installed... processing the menues takes too much time and > > resources as it is, and you want to use up more, for what gain? > > Just how much more time and resources would it take to convert > .desktop files to Debian menu definitions? How often does it have to > be done? 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; what percentage of resources that takes depends on the system... it may be a drop in the bucket for KDE and Gnome users, who are likely to have very capable machines, but what about those who don't have the resources to run KDE or Gnome---why should they be stuck with processing useless stuff they likely can't afford and obviously don't want? The entire menu hierarchy is regenerated everytime a package containing a menu entry is installed or removed. I would like to see: /usr/lib/menu/desktop /usr/lib/menu/desktop/gnome /usr/lib/menu/desktop/kde etc. desktop/ can contain the generic .desktop data (translations and features common to all .desktop aware menu consumers), the gnome and kde dirs would contain the bits specific to them (X-KDE-*, etc.) - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, 10 Dec 2003, Henning Makholm wrote: > Have you quantified the "bloat" you are speaking about? Can the same > argument not apply to any i18n effort? Yes, using KDE2. The script removed any lines with "[""]" in them from KDE files (was possible at the time without incurring breakage) and would typically result in about 5M of disk usage being reduced to a couple hundred K. KDE was also faster processing and accessing its menues, although I did not quantify that aspect (not as easy to do and the difference was obvious enough that I didn't feel the need to hack KDE to put a number to it). Yes, the same argument applies to all i18n efforts. I18n is great, until disk usage and processing times start to climb with no real benefit to individual users. > > Yes, but they would benefit in the same way if the KDE and Gnome > > specific bits were an addendum to the main menu data entries. > > At the cost of a more complicated system, which would by nobody anything. I would hardly call avoiding forcing everyone except KDE and Gnome the need to deal with menu data files which are 10x to 20x the size they need to be `not buying nobody anything'. > > > Just how much more time and resources would it take to convert > > > .desktop files to Debian menu definitions? How often does it have to > > > be done? > > > 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; > > I think we can spare that much memory while generating the menus. memory, disk space, and processing time Maybe you can spare it, I can't, and I suspect those trying to run a light weight system either can't or don't want to. > > I would like to see: > > /usr/lib/menu/desktop > > /usr/lib/menu/desktop/gnome > > /usr/lib/menu/desktop/kde > > But for some reason you're wildly opposed to the idea that .debs can > contain files that populate these directories. Why? Huh, I think you need to do some re-reading. - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 11 Dec 2003, Henning Makholm wrote: > Scripsit Bruce Sass <[EMAIL PROTECTED]> > > On Wed, 10 Dec 2003, Henning Makholm wrote: > > > > Have you quantified the "bloat" you are speaking about? Can the same > > > argument not apply to any i18n effort? > > > Yes, using KDE2. The script removed any lines with "[""]" in > > them from KDE files (was possible at the time without incurring > > breakage) > > Then it's not the format you're opposing, but the inclusion of extra > content in the .debs. Almost correct... I don't think it is appropriate, or fair, that those not using KDE or Gnome should need to deal with KDE/Gnome specific stuff when there are other options. The existing menu data format has a potential problem in that the entries could get too big (too long a line), so a different format wouldn't hurt and may even be a necessity at some point. A single label=value(s) per line, as is used with the freedesktop standard, should be able to handle any amount of menu data items and any reasonable number of values per item. (as you may have noticed) I have a problem with keeping all possible menu data items for an enty in one file. Splitting the menu entry data into generic, KDE, and Gnome 'bins' is a more complex solution than keeping everything in one file, but I don't think the computer cares (and programmers who can't handle it should probably not be doing system level infrastructure programming, eh). Since bloating packages by distributing the generic, KDE and Gnome bits in separate files is almost as bad as forcing all menu consumers to process one large file, it makes sense to distribute the data as one file in the .deb and split it up during installation. Splitting up an all inclusive menu data file into 'bins' should be relatively trivial: generic items go into /usr/lib/menu/, X-KDE|GNOME-* items go into /usr/lib/menu/desktop/kde|gnome/, everything else goes into /usr/lib/menu/desktop/. The only coding needed would be: a program to install the menu data into the appropriate bins, and the KDE/Gnome menu-methods would need to look for more data when building their menues. Ideally, /usr/share/applications and /usr/share/applnk (and the Gnome equivalent) would either disappear or be generated... keeping them as installation targets makes it difficult, if not impossible, to provide system-wide overrides to the packaged menu data. - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 12 Dec 2003, Chris Cheney wrote: > On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: <...> > .desktop files are not bloated... period. They include i18n which for > you is bloat since you obviously can communicate in English. "not bloated... period", yet you admit the translations are bloat for someone who doesn't need them. Can you also accept the X-KDE-* stuff is bloat for every menu data consumer except KDE (ditto for Gnome specials), and that in general freedesktop features are bloat for everyone who doesn't support the freedesktop standard. > As I mentioned further down in this message Konqueror only uses 159 > bytes when all i18n is stripped from it. I see many debian menu > files that are larger than this and they don't contain i18n either. I suspect those files contain more than one menu entry; KDE has a file per entry, menu uses a file per package which contain multiple menu entries. <...> > If several KDE and Gnome developers got together and rewrote the > menu-methods for the various WM's would that satisfy you? No, because it doesn't address the primary concern of (say) a Fluxbox user needing to process the KDE, Gnome, and freedesktop stuff which they don't have a use for. <...> > > 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; > > what percentage of resources that takes depends on the system... it > > may be a drop in the bucket for KDE and Gnome users, who are likely to > > have very capable machines, but what about those who don't have the > > resources to run KDE or Gnome---why should they be stuck with > > processing useless stuff they likely can't afford and obviously don't > > want? The entire menu hierarchy is regenerated everytime a package > > containing a menu entry is installed or removed. > > I call bullshit on this one. desktop files with no i18n are not several > thousand bytes _pre_entry_. And the fact that those other WM's don't > support should be considered a bug not a feature... For example the > Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as > we suggested earlier the Debian menu format gain i18n support then it > would be just as big as .desktop (probably actually since Debian has > very limited i18n support). Ok, the .desktop file sizes are typically between 1 and 2K---but you don't have to look too hard to find 3 or 4K .desktop files, and some of the (admitedly KDE specific) files are over 10K. Yup, that last bit is FUD: I fear it is the future of .desktop files, I'm uncertain they are atypical, and I doubt that 1-2K will be the norm... especially since the example (/usr/share/applnk/konqueror.desktop) you are holding up is 3748 bytes and incomplete (only 7 "Name" and over 3 dozen "Comment" items) on my box (unstable, updated daily). <...> > > desktop/ can contain the generic .desktop data (translations and > > features common to all .desktop aware menu consumers), the gnome and > > kde dirs would contain the bits specific to them (X-KDE-*, etc.) > > Hahaha, you do realize how much extra effort that would entail? It would > be much simpler for the Gnome and KDE maintainers to just rewrite all > the converters and the menu package itself than to keep that up to date. Maybe I don't (although nobody has torn apart my most recent post regarding the scheme)... please enlighten me. - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 12 Dec 2003, Chris Cheney wrote: > On Fri, Dec 12, 2003 at 05:47:17PM -0700, Bruce Sass wrote: > > On Fri, 12 Dec 2003, Chris Cheney wrote: > > > On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: > > <...> > > > .desktop files are not bloated... period. They include i18n which for > > > you is bloat since you obviously can communicate in English. > > > > "not bloated... period", yet you admit the translations are bloat for > > someone who doesn't need them. Can you also accept the X-KDE-* stuff > > is bloat for every menu data consumer except KDE (ditto for Gnome > > specials), and that in general freedesktop features are bloat for > > everyone who doesn't support the freedesktop standard. > > Bloat is relative, since i18n is needed by a large amount of people, > certainly more than need english it is not really bloat. Certainly it > isn't bloat for the 5Bil+ people whose language isn't english. Something > you might determine is a critical feature someone else might consider > bloat. Do the 5Bil+ people need all the translations, or just the few they understand/use. Should one or two someone's critical feature be imposed on the entire population. > Yes, X-KDE-* could be considered to be bloat by some people. > However, the same people who have systems fast enough to actually run > Gnome or KDE also have large enough hard drives that it shouldn't even > be a consideration. Unfortunately, the proposal as I understand it would have everyone getting the X-KDE-* and other specials... even though they may not have the space or processing power to run KDE. > Across all desktop files in the archive that > probably amounts to less than 100KB of additional space. Bitching about a > loss of 100KB when the same packages overall take 500MB+ is very petty. > And no I do not think that the freedesktop standard overall is bloat. Your figures are inaccurate. Based on your own numbers (and being somewhat generous in your favour): Let's say the average i18n-ed .desktop file is 2k, and a non-i18n file is 200 bytes, and there are 2625 of them in the archive... that is 5250k of i18n files and 513k of single language files, a difference of way more than "less than 100KB". The above is just the tip of the iceberg with respect to i18n, I had roughly the same size savings when I was removing translations from KDE2 files---KDE3 has more files, more translations per file, and I haven't looked at Gnome. > > > As I mentioned further down in this message Konqueror only uses 159 > > > bytes when all i18n is stripped from it. I see many debian menu > > > files that are larger than this and they don't contain i18n either. > > > > I suspect those files contain more than one menu entry; KDE has a file > > per entry, menu uses a file per package which contain multiple menu > > entries. > > Yes that is true, so I went and got the konqueror menu file to compare. > Just the one entry for the file browser which is equivalent to the > .desktop file is bigger than the .desktop file without its i18n support. > And add to that the fact that the .menu description is shorter which > further disproves the point that .desktop files are larger. > > .desktop - 159 bytes > > [Desktop Entry] > Encoding=UTF-8 > Type=Application > Exec=kfmclient openProfile webbrowsing > Icon=konqueror > DocPath=konqueror/index.html > > Name=Konqueror Web Browser > > > .menu - 168 bytes > > ?package(konqueror):\ > needs=X11\ > section=Apps/Net\ > hints="KDE,Web browsers"\ > kderemove="y"\ > title="Konqueror"\ > command="/usr/bin/konqueror --profile webbrowsing" The 15 bytes used by the KDE specific "kderemove" line would not be necessary if menues are built from a common data pool (.desktop-159, .menu-153). Also, where is the "Comment" in the .desktop example. I don't see this comparison as meaningful, and even if I did, not significant because the size difference between the two formats is probably somewhere around the margin of error. > > > If several KDE and Gnome developers got together and rewrote the > > > menu-methods for the various WM's would that satisfy you? > > > > No, because it doesn't address the primary concern of (say) a Fluxbox > > user needing to process the KDE, Gnome, and freedesktop stuff which > > they don't have a use for. > > I contend that the processing the time difference would not be sufficient > to tell the difference over extracting and installing packages on the > system. And the only time menus get rebuilt no
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 12 Dec 2003, Moritz Moeller-Herrmann wrote: <...> > Of course the system can and will be improved, once it is generally adopted. Improving it at the outset will speed up its adoption.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, 13 Dec 2003, Billy Biggs wrote: > Bruce Sass ([EMAIL PROTECTED]): > > > The above is just the tip of the iceberg with respect to i18n, I had > > roughly the same size savings when I was removing translations from > > KDE2 files---KDE3 has more files, more translations per file, and I > > haven't looked at Gnome. > > Bruce, > > I can't figure out your position on i18n. Do you think that: > > 1. Debian should only provide english no > 2. Menu entries should be english only no > 3. Packages should individually only include one language no > 4. Packages should include all languages, but only install files > pertinent to the local language s/local language/languages the sysadmin wants installed/ ideally, installing then removing unwanted files is probably more practicable though. > 5. Something else I don't think so > I am just curious because I find your opinion puzzling. None of this > has anything to do with .desktop vs menufile. If i18n support were > added to menufile it would be the same. I prefer the .desktop format, but just switching to it will immediately drag in the translations... is this not the best time to address the issue? - Bruce
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On June 1, 2012 10:00:52 AM Serge wrote: ... > I considered that. I was just trying to keep description shorter and > easier to understand. A more complete description would look like: > 0. fstab is already processed and /tmp was (or was not) mounted to a >separate partition. > 1. init-script cleans it (since it must clean it anyway) > 2. and checks `df /tmp/` for free space and partition > 3.a. if RAMTMP == yes or RAMTMP == no then goto 4 > 3.b. if RAMTMP != auto then print a warning > 3.c. if /tmp is not writable then RAMTMP=yes; goto 4 > 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4 > 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4 > 3.f. else RAMTMP == no > 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space >then RAMTMP=yes > 5. if RAMTMP == yes then mount /tmp to tmpfs > > Maintainer will probably write a better code. Much better... if TMPTIME != 0 it will be necessary to mount the FS based /tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs, then mount --bind the tmpfs on /tmp. Keeping track of whether /tmp was FS or tmpfs based when the system last shutdown could be used to skip all that since RAMTMP=yes implies TMPTIME=0 regardless of the setting in /etc/default/rcS. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206011934.18503.bms...@shaw.ca
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On June 2, 2012 03:48:03 AM Serge wrote: > 2012/6/2 Bruce Sass wrote: > >> Maintainer will probably write a better code. > > > > Much better... if TMPTIME != 0 it will be necessary to mount the FS based > > /tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs, > > then mount --bind the tmpfs on /tmp. > > Oh... I was not thinking about TMPTIME. Does it mean that there's no way > we can mount /tmp to tmpfs because it breaks TMPTIME? no... TMPTIME is currently meaningless (or effectively == 0) when /tmp is a tmpfs, that is simply an expected consequence of keeping /tmp in RAM. It could become meaningful if tmpfs on /tmp's contents were written to disk at shutdown then reloaded at boot when TMPTIME's value is !=0. What it does mean is that automatically changing a system over to /tmp on tmpfs was a bad idea both philosophically and because it could cause data lose; and that there should be a check of TMPTIME's value and the contents of /tmp before any automated mechanism changes to a tmpfs based /tmp, to mitigate the possibility of data loss. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206021602.24750.bms...@shaw.ca
Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch
On June 28, 2012 12:58:09 AM Holger Levsen wrote: > On Mittwoch, 27. Juni 2012, Thomas Koch wrote: > > Thus having said, I believe that the world (and Debians archive) does > > have all the window managers it needs. :-) > > I beg to differ. To say it mildy :) +1 (says the guy building UDE from source) As someone pointed out earlier, there are lots of different tastes when it comes to window manager-like software... I expect there are more tastes than available WMs--so, the more the merrier as long as its maintained. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206280754.45947.bms...@shaw.ca
Re: Recommends for metapackages
On July 10, 2012 10:39:10 AM Sune Vuorela wrote: > On 2012-07-10, Gergely Nagy wrote: > > No. Only if installing recommends is turned on, which cannot be > > guaranteed. > > There is many ways to break your system. turning off installation of > recommends is one of them. So, if Recommends should always be installed--effectively turning them into Depends--why do Recommends exist... Not installing a Recommended package shouldn't break your system, functionality will be reduced but if it breaks then the package probably should be Depended upon or split into depended and recommended upon parts. - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207111652.27393.bms...@shaw.ca
