Re: Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)
* Julien Cristau [110214 15:34]: > On Mon, Feb 14, 2011 at 15:14:04 +0100, Raphael Hertzog wrote: > > > That said helper tools like "dh" should be free to use dpkg-buildflags > > to set environment variables that ./configure and other similar calls > > can inspect and use. > > > The usual way to pass CFLAGS to configure is as a command line argument, > not an env var. That's only available since 1999-10-31 [1], so while it is clearly is the preferred and better way, some tools tend to give them as environment variables. Bernhard R. Link [1] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=7e4902123595c1f31617c15a54b7a0082516d0a5 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214150930.ga2...@pcpool00.mathematik.uni-freiburg.de
Bug#604397: debian-policy: require build-arch and build-indep targets
* Jonathan Nieder [110302 04:03]: > I just noticed this gem in policy §4.9: > > If one or both of the targets build-arch and build-indep are > not provided, then invoking debian/rules with one of the > not-provided targets as arguments should produce a exit status > code of 2. Usually this is provided automatically by make if > the target is missing. That was one of the many tries to get somewherewhere without making non-caring packages buggy. Those attempts have cost us more than 10 years with no result at all. > That doesn't seem so compelling to me; in the failure case, the > autobuilder would just try to pick up where it left off and fail > again, which doesn't sound so expensive. What am I missing? If build is simply a call to a well-behaved make-file, you are right. Sadly well-behaved upstream build systems are not the norm, and the more expensive a package get, the bigger it usually is and thus the more likely something fails in this regard. In some cases that might even be the fault of debian/rules: one usually has to do some preparations before calling make. If those are properly guarded by dependencies on some files (and nothing making those rules phony, as commonly misused patch rules often do), this problem can be worked around. But that does not help if upstream's build system does not behave well. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302085940.ga19...@pcpool00.mathematik.uni-freiburg.de
Re: New field Package-List in .dsc
* Raphael Hertzog [110324 15:14]: > ftpmasters requested a new field in the .dsc files to ease their work. > I just implemented it and it will be part of dpkg 1.16.0. > > This has been done on short notice so I wanted to inform policy people > so that you can review the discussions and the design in case anyone has > objections/suggestions before it's in wide-spread usage: > http://bugs.debian.org/619131 Do I understand this correction correctly that "dpkg-source -b" will generate that when generating a source package (or will this need any changing in scripts calling dpkg-source -b ?) This is put in the .dsc but everything that makes a Sources out of it will need to remove it again (or have an unnecessary large Source file)? If it is only used to give hints to dak, what is the reason that this is in .dsc and not in .changes? (Or perhaps even only in .changes that also include a source package). > It looks like this: > > Package-List: > src:dpkg admin required > dpkg admin required > dpkg-dev utils optional > libdpkg-dev libdevel optional > libdpkg-perl perl optional > udeb:dselect admin optional > > (Here I just marked dselect as being an udeb for a test...) > > The purpose is so that they can setup the overrides for all possible binary > packages as soon as they have reviewed the source package (i.e. and avoid NEW > for subsequent binary uploads introducing binary packages that they have not > yet seen). If it really is in the .dsc files then it would be nice if it also could include the Architecture: of those packages. That would make it easier for things like reprepro to decide if there might be some binary package missing. (Or for other forms of poor-man's stateless wanna-build stuff). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324143741.ga29...@pcpool00.mathematik.uni-freiburg.de
Re: Bug#619131: New field Package-List in .dsc
* Raphael Hertzog [110324 16:20]:
> > If it is only used to give hints to dak, what is the reason that this is
> > in .dsc and not in .changes? (Or perhaps even only in .changes that also
> > include a source package).
>
> Because this is information about the source package and not about the
> upload.
For example until today .dsc files did not contain information about the
Section and Priority of the source package[1]. That information was only
in the .changes file (I guess because it was mostly a hint to
ftp-masters, just like this information is now, too).
> I discarded the .changes because we would duplicate the information in all
> .changes while it's not needed. Putting it only in .changes containing a
> source might be doable but that has never been done before and I'm not
> sure it's a good idea to start with ("fields appearing depending on
> whether a source is uploaded or not").
I'd rather see this as "fields only there if the upload has something to
say in this regard".
Bernhard R. Link
[1] Which is something I'm very happy if it changes[2]. Though having it as
"Package-List:\n src:" is a bit more complicated than just
having Section and Priority fields.
[2] Currently reprepro can guess it by things like parsing a .diff file,
which is code I'd be very happy if I could remove it in some years.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110324183818.ga30...@pcpool00.mathematik.uni-freiburg.de
Re: Patch for MultiarchCross
* Simon McVittie [110408 22:23]: > On Fri, 08 Apr 2011 at 21:51:03 +0200, Bill Allombert wrote: > > Requiring the user to pass -I to the compiler should be discouraged. > > I disagree: independently of multiarch, many libraries do this deliberately > to allow for parallel-installation, and use pkg-config to give out appropriate > CFLAGS. -I is not CFLAGS but CPPFLAGS. > For instance, you can have libgtk2.0-dev and libgtk-3-dev installed > at the same time, even though they both include (for instance) > ; using -I/usr/include/gtk-2.0 or -I/usr/include/gtk-3.0 > (or in practice, asking pkg-config for gtk+-2.0.pc or gtk+-3.0.pc) selects > the desired API. That's simply gtk prefering windows style development. If they made it proper part of the headers to #include there would be no problem and it would even work with different plugins of some program using different versions. Gtk simply is not a good example for any sane library handling, as it insists of inventing it's own way for everything. (Just think of the inlining of other libraries' functions so one never can know that libraries are actually used). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110410132858.ga9...@pcpool00.mathematik.uni-freiburg.de
Re: Bug#628515: recommending verbose build logs
* Matthias Klose [110529 20:03]:
> without knowing how the compiler or the linker were called. Maybe it is
> convenient for a package maintainer watching the build scrolling by (some of
> these are even colorized), but lacking this kind of information in the first
> place seems to be the wrong thing.
I think it is also a good thing to propose upstreams to not do this
madness by default. In many support channels the first thing you often
have to ask it to get a proper build log. Defaults of build systems
should be tailored towards users, not towards developers.
> The majority of quiet build logs comes from cmake based systems and (newer)
I think cmake has the additional problem that it misses a proper middle
ground, without verbosity it is says not nearly enough, with verbosity
it gives quite more output than a classic automake like build system.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110530085113.ga4...@pcpool00.mathematik.uni-freiburg.de
Re: Bug#604397: debian-policy: require build-arch and build-indep targets
* Steve Langasek [110604 05:27]: > If we're willing to flip the switch on the autobuilders and force > maintainers to deal with the breakage, we don't need a policy "should" > either... we can go straight to a policy "must" as soon as the switch is > flipped (and we should flip that switch *ASAP*, not let this question drag > on any further into the release cycle). Having seen this discussion now for almost a decade with people claiming smooth transitions coming really soon, I think this is the only way unless someone can actually show something for the buildds working now (and not in some months, because it has been months for years now). > > It probably needs a little more polish (testsuite support) before it can > > be applied, but the core checks are done. > > Unfortunately I see the same problem with this lintian check as with all the > rest - if we can actually check for the existence of the target *reliably*, > then we don't need to enforce its presence at all. Lintian checks do not need to be as reliable. (Reliable tests are better, but hardly any lintian check is as reliable to an extent people seem to require for a build time build-arch check.) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110604101745.ga30...@pcpool00.mathematik.uni-freiburg.de
Re: Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means
* Jonathan Nieder [110715 22:18]: > For the former (license upgrades), the Debian maintainer should also > patch the source files to make the change, right? If that's done, > then I agree that it seems reasonable. > > For the latter (license explanation), I also agree it's reasonable. > "A verbatim copy" has always been a somewhat problematic phrase > because in practice it's not the words that matter but the meaning. > When describing the license of binaries, of course it is more valuable > to document the actual license the user has than the separate licenses > of the components used to build it. I think the "verbatim" is extremly important. Meaning is always a matter of interpretation and no maintainer can claim to have a perfect understanding. Misunderstanding and changing something out of a wrong understanding is very similar to willfully misinterpreting the author's wishes and permissions. Similar enough that in the end a judge has to decide what it was. You should never change what is in source files. If you think it is important you can amend it. (Like: "Due to licenses in other files, your only option here is " or "The README also grants the following rights: ..." or so on). Also the debian/copyright should always contain the verbatim grant of the license. If that points to additional material, it might not be necessary to include ineffective/unused parts this points to, but at least the license grant itself should be there as verbatimly as possible[1]. If anything is unclear, make it clear and give the additional information, but do not make it look like it is what the author wrote, unless it is what the author wrote. > debian/copyright describes the license users get, while "egrep -R -e > (opyright|icense|ublic)" in the source package gives the upstream > granted license. So I think we're doing fine on that front. :) We are no legal entity that can protect our users against any claims, our users face the problems if there are any, so they should be able to make an informed decision from looking at debian/copyright. And not be mislead to think everything is fine just because we thought it is and thought it would be a clever idea to hide any discrepancies away. Bernhard R. Link [1] Exceptions are usually removal of indendation/comment characters/ line splitting, deduplication and things like that. Even for the common (and for readability quite important) consolidation of copyright statements with different years I'd not be suprised if there are same lawyers out there advising against ist. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110716112447.gb7...@pcpool00.mathematik.uni-freiburg.de
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
* Russ Allbery [111026 00:43]: > I think it would be lovely to just use RFC 2119 language or a close > adaptation thereof. We're sort of reinventing the wheel here, There is also those previous art called "language". I do not think it makes sense at all to switch from the wheel to some cogwheel when still wanting to run on roads. > RFC 2119 solves the problem of indicating > that these words have specific meanings by putting them in all caps when > they're used with specific definitions. That's a totally different way to express things. There are not only some little wording difference. Having to have some all-upercase "MUST" in every second sentence is not only ugly but would not improve policy at all. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111026132910.ga3...@server.brlink.eu
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
* Russ Allbery [111026 19:12]: > "Bernhard R. Link" writes: > > * Russ Allbery [111026 00:43]: > > >> I think it would be lovely to just use RFC 2119 language or a close > >> adaptation thereof. We're sort of reinventing the wheel here, > > > There is also those previous art called "language". I do not think it > > makes sense at all to switch from the wheel to some cogwheel when still > > wanting to run on roads. [ignoring ad hominem attacks given here, to avoid returning them...] > The previous art called "English" developed for day-to-day human > expression and is poor at formal specifications because so many words have > multiple alternative meanings and can carry different levels of weight in > different contexts. Particularly when one has a substantial number of > non-native readers who aren't going to pick up on subtle nuance, this just > doesn't work. This is something that basically every standards body has > confronted at one time or another in the past. If you wanted to replace policy with a formal set of requirements and descriptions like RFCs have them, then this argument could hold. But transforming policy into this is illusory and I doubt it would benefit much. It's a mixture of descriptions, requirements and rationals. Each of them living on one of many different levels (while generally rather describing the higher levels, leaving lower level stuff to the implementation (i.e. dpkg and dak). It's a set of rules to be used on top of the implementation to allow us to build a coherent system. Just take a look at the section "Binary packages" and notice what is not described in there. (And for people suggesting to use some RFC like description and thinking that is possible, what would you make out of the current 3.1, 3.2, and 3.2.1 for example?) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027091853.ga3...@server.brlink.eu
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
* Julian Gilbey [111027 12:09]: > 3.2: Unchanged, So a package without a version is fine? > except in final paragraph where "should be converted" > is changed to "SHOULD be converted". So you suggest to change policy so that this is no longer a bug if not done? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027131114.ga24...@server.brlink.eu
Re: Bug#654958: debian-policy: Document VCS fields.
* Russ Allbery [120107 17:51]: > > I wonder if something like > > > Vcs-Git: git://git.eyrie.org/kerberos/webauth.git squeeze > > > could be made to work. > > My understanding was that the debcheckout developers were not enthused > about adding a syntax that Git upstream didn't support, but I think that's > the only solution that anyone's come up with so far. Something that was only added to git after that discussion was already running for a while is git-clone's -b. Sadly Vcs-Git: git://git.eyrie.org/kerberos/webauth.git -b squeeze does not work as debcheckout is not word splitting the argument, but the error message at least cites a command one can just copy to the shell and it will work. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120107173722.gb29...@server.brlink.eu
Bug#654958: debian-policy: Document VCS fields.
* Russ Allbery [120107 20:42]: > "Bernhard R. Link" writes: > > Something that was only added to git after that discussion was already > > running for a while is git-clone's -b. Sadly > > > Vcs-Git: git://git.eyrie.org/kerberos/webauth.git -b squeeze > > > does not work as debcheckout is not word splitting the argument, but the > > error message at least cites a command one can just copy to the shell > > and it will work. > > I wonder if the debcheckout developers would be willing to adopt this > syntax, since that seems like a nice solution. I just submitted http://bugs.debian.org/655085 with a patch. Hopfeully that either is accepted or gives some response what a acceptable solution would need to look like... Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120108143107.ga3...@server.brlink.eu
Re: Bug#638060: debian-policy: §9.1.1: FHS should also be a "must" for generated files
* Russ Allbery [120227 19:03]: > Jonathan Nieder writes: > > Russ Allbery wrote: > > >> + The location of all files and directories must comply with the > >> + Filesystem Hierarchy Standard (FHS) > > > Unfortunately, I don't think that matches the old intent. This sounds > > like a restriction on the admin. I'm particularly worried that people > > could use this as justification for packages assuming that all files and > > directories comply with the FHS, instead of coping with the real world > > Could you be more specific about exactly what behavior you're worried > about? I thought about this for a while before making this change and > can't think of any place where this would realistically affect packages. > > Note also that Policy is specifically Policy *for Debian packages*, so we > don't need to worry that Policy imposes restrictions on what admins do. > It can't; that's out of scope. I guess it could be misunderstood about what kind of files and directories a package may expect: If a package deletes all top-level directories not allowed by FHS or mentioned by Debian policy, is that a violation? If a package fails to work with home directories in /user or a package fails to work with TMPDIR=/tempshares/username, is that a bug in the package? The answers to all those questions should be obvious, but as people like to make policy more explicit and less interpreted with common sense, it might be good to be more explicit about that. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120227193203.ga1...@server.brlink.eu
Bug#571776: document symbols
* Russ Allbery [120317 19:17]: > These two mechanisms differ in the degree of detail that they > provide. A symbols file documents every symbol > that is part of the library ABI and, for each, the version of > the package in which it was introduced. [...] This is misleading. It's about when the symbol with its current meaning was introduced but could be easily misunderstood to mean the first introduction (and some people might not read the later explanations). How about something like | [...] A symbols file documents for each symbol | exported by a library the minimal version of the package any | binary using this symbol will need. [...] > shlibs files also have a flawed representation of > library SONAMEs, making it difficult to use shlibs > files in some unusual corner cases. Only stylistics: How about not using "flawed"? Something like "Also the way library SONAMEs are represented in shlibs files makes it difficult to use them in some unusual corner cases."? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120324152733.ga20...@client.brlink.eu
Re: Proposal to update NMU section 5.11.1
* Charles Plessy [120426 02:08]: > Thanks for the information, I thought it was obsoleted when the closing of > bugs > became versionned. Before closing become versioned, the situation was more complex: Before, a upload of a .changes would behave differently depending whether it was a NMU or not. If it was a MU then there were mails to -d...@bugs.debian.org sent (just as they are now) but if it was a NMU, then this was not done. Instead those bugs got the tag "fixed". Thus if you acknowledged an NMU with the following MU, you had again close all the bugs in the new changelog of the package (so they would now be properly closed). This was necessary to avoid bugs being closed in a NMU but that change being silently reverted by the maintainer uploading a new version ignoring the NMU. For example that looked like | e2fsprogs (1.38-2) unstable; urgency=low | | * Previous NMU acknowledged (Closes: #317862, #320389) | [...] Since bug-closing is versioned that is no longer necessary. bugs.debian.org keeps the information about what version a bug was closed in and has the information which version is based on which version. Thus if there is now a .changes uploaded, the bugs it closes are closed, no matter if it is a MU or a NMU. And the bts keeps track if those bugs are closed in the current version. So a bug only marked to be closed in 1-1.1 will be consider open in 1-2 in the left case, but consider closed in 1-2 in the right case: 1-2 1-2 | | | 1-1.1 1-1.1 | / | 1-1 1.1 To get the information, which package is based on which package, the debian/changelog file is considered, so you need to have the NMU's changelog there. (Or you need to close all those bugs again, like it was done before versioned closes where introduced). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427090702.ga10...@client.brlink.eu
Bug#654958: debian-policy: Document VCS fields.
* Bernhard R. Link [120108 14:03]: > * Russ Allbery [120107 20:42]: > > "Bernhard R. Link" writes: > > > Something that was only added to git after that discussion was already > > > running for a while is git-clone's -b. Sadly > > > > > Vcs-Git: git://git.eyrie.org/kerberos/webauth.git -b squeeze > > > > > does not work as debcheckout is not word splitting the argument, but the > > > error message at least cites a command one can just copy to the shell > > > and it will work. > > > > I wonder if the debcheckout developers would be willing to adopt this > > syntax, since that seems like a nice solution. > > I just submitted http://bugs.debian.org/655085 with a patch. The patch was applied to debcheckout, so Vcs-Git: can now specify a branch to use. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120509183222.ga30...@server.brlink.eu
Bug#654958: debian-policy: Document VCS fields.
> + > + Vcs-Arch, Vcs-Bzr (Bazaar), Vcs-Cvs, > + Vcs-Darcs, Vcs-Git, Vcs-Hg > + (Mercurial), Vcs-Mtn (Monotone), Vcs-Svn > + (Subversion) > + > + > + > + The field name identifies the VCS. The field's value uses the > + version control system's conventional syntax for describing > + repository locations and should be sufficient to locate the > + repository used for packaging. Ideally, it also locates the > + branch used for development of new versions of the Debian > + package. > + > + > + In the case of Git, the value consists of a URL, optionally > + followed by the word -b and the name of a branch in > + the indicated repository, following the syntax of the > + git clone command. If no branch is specified, the > + packaging should be on the default branch. > + Why only document git and not the syntax of the other fields? cvs: a identifier suiteable for cvs -d (i.e. usually starting with :pserver:), followed by an optional module name (seperated by a space). I think it might also make sense to explicitly request that the fields should describe an anonymous checkout. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716051651.ga12...@client.brlink.eu
Bug#397939: clean rule behavior underspecified and inconsistent with common practice
* Jonathan Nieder [120911 05:45]: > > during the last months i had to review several packages. Quite a number > > of packages were not buildable two times (eg. "unrepresentable changes > > to source"). Most of these packages used svn-buildpackage or > > cvs-buildpackage. This bug is quite annoying as one needs to either > > manual interact or run dpkg-source -x again. > > Of course policy forbids that. The requirements in policy for > "debian/rules clean" are very stringent --- to avoid the > "unrepresentable changes" it would be enough to _remove_ the modified > (regenerated) files, but policy requires undoing everything the build > target did, or in other words restoring the original files. I disagree. Policy says: | This must undo any effects that the build and binary targets may have | had, except that it should leave alone any output files created in the | parent directory by a run of a binary target. It does not do it must undo "everything". Undoing everything would be impossible (like, how do you revert the timestamps of directories that got a newer timestamp because there was a file created and then removed in there?). Policy only speaks about the "effects" those targets had. And I think common understanding of this was (at least was in the past) that removing files not needed for the build is a simple and effective way to undo those effects, as it results in a working dir aquivalent for all practical purposes to one where build and binary never ran. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012093545.ga1...@client.brlink.eu
Bug#679326: debian-policy: DMUA should covered more explicitly
* Russ Allbery [121002 02:21]: > (I'm rather dubious this change in the upload process of the project can > be constitutionally made without a new GR, but I think it's a good idea > and I think that limitation is solely due to a bug in the original GR, so > I don't see much point in arguing about it.) Didn't the GR spoke about the "The initial policy" exactly to make sure such a purely technical change like this does not need another GR? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121002061402.ga18...@client.brlink.eu
Bug#707851: Please do not remove menu before .desktop is fixed (if it ever will be)
Some points for a having menu files: - it is supposed to include all programs, and does not do choices like "you don't want that program" - it is properly documented (like how do I as administrator override and change a menu setting globally). - it is properly documented for maintainers - there is still no policy for .desktop entries (a standard describing the format is no policy) - it can express features modern DEs lack (like switching between different environment without closing programs). As I think it is unlikely that there will be a policy to fit all of this together (especially the "what to show in which program"), I'd suggest to just have menu and .desktop entries in Debian packages that way: - we can keep the Debian menu with all programs in it - the newfangled DEs can have .desktop as their playfield where usefull but to ancient looking programs are not exposed to their users by not having a .desktop entry, Gnome programs can have their OnlyShowIn=Gnome so no other newfangled DEs sees them but with a menu entry users of classical window managers could still start them and so on. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512103626.ga4...@client.brlink.eu
Bug#707851: Please do not remove menu before .desktop is fixed (if it ever will be)
* Josselin Mouette [130512 12:55]: > Le dimanche 12 mai 2013 à 12:36 +0200, Bernhard R. Link a écrit : > > Some points for a having menu files: > > > > - it is supposed to include all programs, and does > > not do choices like "you don't want that program" > > In my opinion, this is an anti-feature. A menu is not some random place > to shove all your programs. It is a key part of the user interface, and > needs to be thought as such. Both "show everything" and "show only what we think you would want" are both features. Both have their pros and cons. If one of them has to be named "anti-feature" then I'd nominate anything that hides stuff from me or makes the menu different with the different Environments. I really love how with the Debian menu the menu simply looks the same with every environment. I can just point people where to find a program. Everything is in there and everything looks the same everywhere. That's really nice if you admin some university computer lab where people use two dozen different environments. > > - it can express features modern DEs lack (like switching > > between different environment without closing programs). > > This is the perfect example of an anti-feature. Who needs that? What is > the use case? I think you use a different definition of "anti-feature" than everyone else. "Anti-feature" does not mean "I do no like it". > Selection should be done once from the login manager, in > the real world no one needs to dynamically switch WMs. I do so regulary. Different systems have their ups and downs and switching them on the fly if some program has problems with one of them really makes you get the best of all worlds. > All in all I don’t see why we couldn’t just drop menu altogether or > replace it by a XDG menu implementation. In all cases, it doesn’t have a > place in the policy anymore. I'm not opposed to dropping menu and using XDG menu implementation. But then we should have a policy that XDG menus only do ShowOnlyIn= if there is a technical reason something does not work and not only because the maintainer thought "not interesting for others". Then everything that can be started via a menu should have a menu entry. As I doubt we can get that easily, it might be just best if everything has their debian menu entry so .desktop does not need to be pestered with all the "anti-features" you do not like. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512130335.ga4...@client.brlink.eu
Re: Bug#707851: debian-policy: soften the wording recommending menu files
* Bill Allombert [130515 12:54]:
> The menu layout files are XML. While the standard does not mandate the use of
> XSLT, it requires manipulation of XML files which are equivalent to XSLT
> processing.
Window managers do not really need to be exposed to this format. The
menu program could just read .desktop files and generate a menu for the
window managers using the already existing menu-methods.
The format is not really the problem. The problem is the missing
contents of desktop files.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130515164346.ga3...@client.brlink.eu
Re: Bug#748936: apt doesnt understand architecture wildcards
* Johannes Schauer [140522 13:30]: > Debian policy 11.1.1 [1] and the associated footnote [2] allow > architecture wildcards of the form os-any and any-cpu. Apt seems to > equal "cpu" with "debian architecture" which is not correct. Here is an > example of correct matching: > > dpkg-architecture -aarmhf -iany-arm && echo "any-arm matches armhf" > > Apt would instead only match the deprecated "arm" architecture with > "any-arm". This doesnt seem to be a problem in practice though because: > > 1) apt does not check whether a source package can be compiled on the > current host architecture (it ignores the Architecture field of > source packages) > 2) all packages that have any-arm in their build dependency > architecture restrictions also include any-armel, any-armeb and > any-armhf > > Nevertheless, apt behaviour should reflect dpkg behaviour and naturally > policy. The correct behaviour is encoded in dpkg scripts/Dpkg/Arch.pm > and needs the files /usr/share/dpkg/triplettable and > /usr/share/dpkg/cputable to work correctly. Urgh. Really? This is far too complicated for most programs to implement properly. I'd suggest to rather fix dpkg (and also fix policy. The footnote describes absolutely nothing currently, and having such important fields a meaning that you cannot calculate without knowing what architectures the system finally using the package uses makes it unhandable). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140525200448.ga21...@client.brlink.eu
Re: Bug#748936: apt doesnt understand architecture wildcards
* Russ Allbery [140525 22:58]: > > and having such important fields a meaning that you cannot calculate > > without knowing what architectures the system finally using the package > > uses makes it unhandable). > > I'm not completely sure what you mean by this, but if you mean that you > can't know what architecture strings are valid without knowing which > architectures are supported by dpkg, I think that's a feature in Policy, > not a bug. I wouldn't want to update Policy every time a new architecture > was added. That happens quite frequently. I mean that no tool can give meaning to those strings without having the full architecture table of the dpkg on the machine where this is to be finally interpreted. (Which especially means that any tools trying to interprete anything with those wildcards needs something from a dpkg that already knows those architectures.). Something like a "any-FOO" matching any debian architecture "*-FOO" and "FOO" would be something simple. Having magic like any-arm also matching armhf means it cannot be processed without having special knowledge of the architectures. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603220205.gb3...@client.brlink.eu
Re: Bug#748936: apt doesnt understand architecture wildcards
* Guillem Jover [140604 03:42]: > * Other programs could “easily” use dpkg-architecture to check for >identity or a match. (This poses problems for programs that do not >want to either require dpkg around or to fork its tables.) That assumes that dpkg knows the arechitecture already on the system you need the information. Take for example something looking at build dependency information to queue builds on other systems. Or something creating a partial mirror of a repository containing what is needed to build specific packages on some architectures. If the only way is "call dpkg-architecture" then this host needs to run the newest dpkg in order to be able to also be able to handle new architectures. And on infrastructure hosts you usually prefer to just run unmodified stable. > * We need a unique 1:1 bi-directional mapping from GNU triplets to >Debian architectures, some of the properties are hidden and need >to be internally expanded. > * Because those hidden properties are implicit, they require a table >which might not be known by other programs anyway. > * Matching on cpu instead of arch name, was the logical route once >the architectures had been expanded into their normalized forms >(the Debian triplets). The question is: Why should the wildcards be able to match about details only visible in the triplets. A wildcard that just matches "Debian architecture without the kernel" would be much easier to implement and not need additional knowledge (except some easy to builtin "if there is no - then it is an implicit "linux-*"). > * Matching on cpu instead of arch name, supposedly made adding support >distribution-wide for things like armel or lpia way easier. (This >might not have been worth it though.) Indeed, while it makes adding architectures similar to existing ones a bit easier, it might make creating new architectures that much harder in return (due to needing a patched dpkg even on other architectures first). And is one even able to express things like "only build depend on this on armhf but not on armel"? > But, I agree this might seem confusing, and that's why I left #694630 > open, because I want to deal with it some way or another. I'd have to > check if it would be feasible to match against the arch name instead of > cpu name, but even if there was no fundamental blocker there, changing > that now would imply a backward incompabitble change, and would require > at least someone going over the archive and taking care of any fallout > beforehand, and that does not cover out-of-archive packaging and > infrastructure, etc. So I'm not sure this seems appealing… but I'll > make a note of at least checking it. At least I'd suggest to not allow it in the Debian archive yet. Not everything dpkg supports must be allowed by policy. (Like upper case letters in package names). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140606155617.ga2...@client.brlink.eu
Bug#758234: it's actively harmful
* Matthias Urlichs [141029 19:48]:
> That's obvious. What is not so obvious, to me, is why we would still
> want the current policy in the first place, given that everything(?)
> is resolved via dependencies these days.
Resolving dependencies is a hard and complex task. In general it will
not even have a unique solution. And virtual packages, alternatives
and versioned depends needs more complexity (including backtracking
to find solutions) than most tools can do.
As long as only a small number of packages have the wrong priority,
starting with that set and pulling the rest in via dependencies is
likely to not run into any ugly problems. So simple algorithms have
a chance.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102185920.ga4...@client.brlink.eu
Bug#758234: it's actively harmful
* Matthias Urlichs [141103 07:48]: > > As long as only a small number of packages have the wrong priority, > > starting with that set and pulling the rest in via dependencies is > > likely to not run into any ugly problems. So simple algorithms have > > a chance. > > > I'm not saying that we should immediately replace Required and Important > priorities with two metapackages (which would depend on every top-level > package that's currently marked as such). That'd be too complex for simple > tools like debootstrap. > > What I am saying is that if package A is Important / Required and has a > simple dependency on B, then (absent any Pre-Depends) the priority of B is > not relevant any more and thus doesn't need to be overridden. And what about the dependencies of B? Is it allowed to have non-simple dependencies in your suggestion? Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141104185433.ga2...@client.brlink.eu
Re: Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary
* Steve Langasek <[EMAIL PROTECTED]> [080605 19:04]: > This is not part of the rationale for a package's inclusion in Essential, > it's an effect of a package's inclusion in Essential. > > Packages should only be in the Essential set if they have to be there to > guarantee the operation of dpkg. I've experimented recently with some more minimal build chroots (even dropping some essential stuff), and I do not think that above matches the current situation. I think currently it is more of "if they have to be there to garantee a working system". Things like passws, sysvinit, mount, e2fsprogs, sysvinit-utils, libpam-modules or login are as far as I can tell not needed at all to have dpkg functionally, but as far as I can guess are only essential because removing them would bring a non-chroot system easily in an unusable state. (Surprisingly many things even still work without util-linux, though splitting it into a mkfs*/fsck* part (which needs the libuuid1 dependency which again pulls in passwd, which again pulls in more stuff) in an extra package seems a more sensible choice if things were to change in a way to allow more minimal build chroots). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
* Daniel Dickinson <[EMAIL PROTECTED]> [080705 09:05]: > xdg .desktop-based menus are not covered by policy. I think this is an important point to acknowledge by all people wanting to see more .desktop files: There is no policy how to use the fields in them. Currently most people just copy the files from their upstreams. That cannot work to get a coherent system. When Debian packages use .desktop files from other packages in Debian, there should be a Debian policy what those files may contain and what not. The system also misses massively documentation. Perhaps it got better in between, but last time I looked it totally missed any documentation except and lengthy document that seemed to be targeted on writers of menu programs displaying. Nothing how to overwrite items as user, not wher to put them to test them, not even the actual paths (only some placeholders without explanation everywhere). > The main menu (meaning the primary menu used for program selection; I > don't include quick access menus which have a small selection of often > used programs) should either be the debian-menu or all packages which > are supposed to have menu entires should also be required to > supply .desktop files. > > Having a dual-menu scheme in policy is ugly. > > Currently the debian-menu is a submenu of the main menu, called > 'Debian'. This is indeed very ugly. But I think that is not so much a technical problem, but more a problem of different opinions what a menu should be like. Because from what I gathered in the previous discussions about this, an important reason gnome and kde maintainers refuse to use the Debian menu is that then all the programs (even the text and "ugly" X programs) would be in the menu equal to the other ones. Switching to .desktop files would of course not fix that, as then all the other programs would have .desktop files, too. The Debian menu system could easily be extended to have some more tags describing such properties (perhaps some ShowAlsoInKDENoviceMode tag or whatever), but that would need an honest discussion about the aims. > desktops that want to have .desktop entries for specific programs ought > to be responsible for creating the code that merges the debian main > menu with their main menu (e.g. in menu-xdg), rather than forcing every > other application in debian to do their work for them. I think the easiest solution would be to have some additional tag that menu-xdg uses to filter out menu entries that also have a .desktop file. (hopefully it already has, that only needs documentation, otherwise it should be added), and then policy should say that each package should use this tag to specifiy which entries in the Debian menu are duplicated by a .desktop file. Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#514919: Removing support for uploads to multiple distributions
* Adam D. Barratt [090211 22:30]: > The Policy section detailing the "Distribution" field in .changes files > specifies that the field may contain a space-separated list of > distributions. Whilst this is technically accurate, the feature has been > deprecated since the "testing" distribution became an official part of > the archive and is, imho, obsolete; the use case of uploading the same > package to unstable and the frozen-stable-to-be as a single upload no > longer applies. > > I discussed this with a couple of members of the ftpteam on IRC earlier > today, and they were both in favour of removing support for the feature > from dak. One of them had a dig through the archives and discovered that > there have been no multiple-distribution uploads since 2004; even then > there was only the one upload in that year, with the grand total of > three in 2003. I agree that this is no longer needed within Debian, but I think it is still a usefull feature and use it a lot in local repositories, so would like to have changes handling tools continue to support it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522217: debian-policy: Drop requirement to pre-depend on x11-common
* Bernhard R. Link [090621 16:10]: > > Configuration files for window managers and display managers > > may be placed in a subdirectory of /etc/X11/ > > corresponding to the package name. Other X Window System > > applications should use the /etc/ directory for > > configuration files unless otherwise mandated by policy > > (such as for ). > > > > How about other things tightly integrated to some part of the X window > system. There aren't that many Xt applications, but they use files in > /etc/X11/app-defaults/ to configure at least the interface, so this > should still be allowed. I should read sentences to an end, no please disregard my comment about app-defaults. But I still uphold the other point: > I also think "window managers and display managers" is too strict. I > think it should rather be something that is not primary an single > application that happens to use X but everything that extends X in some > way (for example X Input Methods, or for example my package choosewm). (I forget "session managers" as an obvious example, too) Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#522217: debian-policy: Drop requirement to pre-depend on x11-common
* Russ Allbery [090620 23:55]: > Raphael Hertzog writes: > > > On Fri, 19 Jun 2009, Russ Allbery wrote: > >> + Configuration files for window managers and display managers > >> + should be placed in a subdirectory of /etc/X11/ > >> + corresponding to the package name due to these programs' tight > >> + integration with the mechanisms of the X Window System. > > > > I'm not sure we need that. awesome (the wm) for instance has config files > > in /etc/xdg/awesome and I don't see why it should be moved to /etc/X11. > > I'm not sure either. This was already in Policy prior to this round of > changes, of course, but maybe since we're revising this section anyway, > this is the time to remove it. To remove it, I'd drop the should and > turn it into something that we permit, like: > > > Configuration files for window managers and display managers > may be placed in a subdirectory of /etc/X11/ > corresponding to the package name. Other X Window System > applications should use the /etc/ directory for > configuration files unless otherwise mandated by policy > (such as for ). > How about other things tightly integrated to some part of the X window system. There aren't that many Xt applications, but they use files in /etc/X11/app-defaults/ to configure at least the interface, so this should still be allowed. I also think "window managers and display managers" is too strict. I think it should rather be something that is not primary an single application that happens to use X but everything that extends X in some way (for example X Input Methods, or for example my package choosewm). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542865: Grant an FHS exception for the multiarch library directories
* Steve Langasek [090821 23:56]:
> We are approaching the point at which it will be useful to begin having
> packages in the archive that install to the multiarch library paths
> ({/usr,}/lib/), for use with the multiarch-capable package manager
> that's in progress. However, installing libraries to these paths instead of
> directly under {/usr,}/lib is an FHS violation and therefore is currently a
> Policy violation as well.
What are the chances that exactly those directories will end up in future FHS
versions? I could not find anything indicating any coordination on that
on fhs lists. Is there some coordination somewhere else?
Bitten by every second release changing where sparc64 stuff is at the
sparc platform and almost each of those transitions breaking my systems
in some way, I'd prefer if everything possible is done to avoid
changing it again with the next or next but one release again.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542865: Grant an FHS exception for the multiarch library directories
* Steve Langasek [090822 22:11]: > > What are the chances that exactly those directories will end up in future > > FHS versions? > > Why do you want me to speculate on the *chances* of its inclusion? Preferably I'd like some arguments that ther is a high chance of its inclusion. > my understanding of the FHS is that they only incorporate things > into the standard for which there's a deployed implementation. That's my understanding, too. I'm not asking to delay this until it is in FHS. All I want to know if this is some isolated "let's try this and tell noone about and if we are fast enough the others might follow" or if it is some "We spoke with some others and they see no problem with this scheme and will follow and put in FHS if that works for us". > > Bitten by every second release changing where sparc64 stuff is at the > > sparc platform and almost each of those transitions breaking my systems > > in some way, I'd prefer if everything possible is done to avoid > > changing it again with the next or next but one release again. > > I frankly have no idea what you're talking about. I'm not aware that 64-bit > libraries were ever placed anywhere other than [...]/lib64 on sparc, For example take a look at woody: |>dpkg-deb -c fakeroot_0.4.4-9.2_sparc.deb | grep 64 |drwxr-xr-x root/root 0 2001-05-12 05:51 ./usr/lib/64/ |drwxr-xr-x root/root 0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/ |-rw-r--r-- root/root 24552 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so.0.0.1 |lrwxrwxrwx root/root 0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so.0 -> libfakeroot.so.0.0.1 |lrwxrwxrwx root/root 0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so -> libfakeroot.so.0.0.1 |>dpkg-deb -c libc6-sparc64_2.2.5-11.8_sparc.deb | grep \/64 |lrwxrwxrwx root/root 0 2005-01-07 17:49 ./usr/lib/64 -> ../lib64 |lrwxrwxrwx root/root 0 2005-01-07 17:49 ./lib/64 -> ../lib64 I can guess you can imagine what happend when upgrading in half of the cases... Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542865: Grant an FHS exception for the multiarch library directories
* Steve Langasek [090823 21:51]: > Oh; so "every second release" -> "one release, 7 years ago, in which there > was a bug". Thanks that you point out my mistake in so nice terms. I'm pleading guilty of the high crime of doing an estimation and erring by 100% (25% of all releases with sparc64 libc I can show evidence of brokeness while "every second" of course can only mean exactly "50%"). Now that you have successfully attacked my reputation, could we return to the point of my actual question: Do I conclude correctly that there is no coordination with other distributions at all for this chance and you have no idea if those paths will be the final or need some transition (which of course will be no problem unless someone adds some of those nasty "bugs" again). Or are there any facts that would appease my mind that you did not give because I would not understand them anyway being so ridiculous as I am? Thanks in advance, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543417: README.source patch system documentation requirements considered harmful
* Chris Lamb [090908 02:02]: > > Such phrasing will result in README.source files saying > > > > "This package uses quilt, as documented in > > /usr/share/doc/quilt/README.source" > > Whilst I quite like the idea of allowing source documentation to be > satisfied by build dependencies, a single-line README.source still has all > the drawbacks I originally filed this bug about. > > That is to say, the existence of your README.source file would still be a > false-positive when looking at the package with respect to whether it is > esoteric in some way. Raphael Geissert also argues this in #73. I think having short README.source is better than having none. If there is a short one in normal cases, people can always look at it and see at one glance whether it is what they expect or if it needs special consideration. Some bonus point is that there is a proper transition path from the old way of not having such a file. Becaus if there is a short file that says "nothing special here" that is a defined state and you know someone added it. If there is no file you do not know if that means "nothing special here, ignore debian/patches as it is preapplied in .diff.gz" or "nothing special here, standard quilt patching done at build time" or "this package may do something special but noone has yet looked at it". Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561828: debian-policy: add restriction for non arch all packages
* Carl Fürstenberg [091220 15:51]: > currently section 5.6.8 doesn't say when a package should be in arch > all except when source package is arch all (which in turn gives the same > argument). > I think following statement should be added: "If the content of a > package is architeture independent in relation to it's particular use, > then the package must have architecture 'all'". I think if it is deemed necessary at all to formulate it, it should give the real rule: "If a package built on one architecture can be used on all architectures, ..". There is at least the case of different dependencies per architecture, which cannot yet be expressed in an architecture all package. Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
* Joerg Jaspert [100106 09:48]: > >> * Whether it makes sense given Debian semantics or not, users just don't > >> expect removing packages to, from their perspective, destroy data. > >> Other distributions don't seem to do this. > > We are talking about "purging", not "removal", thus I consider this argument > > invalid. I expect "purge" to remove all traces of a package from the system. > > So when I purge OpenOffice.org from my system it should then delete all > the documents created with it? They are about the same category: Created > with the software packaged here, but not related to it otherwise, its my > data. Your data in in $HOME. Purging should not change there anything. But I totally expect it to remove all system wide settings of Openoffice like global printer settings and all modifications to system directories not done by myself (where "done by myself" can include doing by the program as safe-as, but only when I control the location and not if the program does it and especially not if it does not even show me where it happens). On other words: as a quick test: if I only use a program as user and purge the package and my $HOME (and perhaps /tmp by reboot), there should be nothing left and especially when I reinstall it everything should be as after the first installation. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571776: debian-policy: Libraries should be allowed to not provide shlibs when they provide symbols file
* Mike Hommey [100227 23:53]:
> AFAIK, the current version of dpkg in stable supports symbols files, so I
> think it is time we loosen the requirement for shlibs files when symbols
> files are present.
>
> Requiring shlibs when there is a symbols file also is error-prone, as when
> the symbols file is updated, the shlibs may not be bumped.
Perhaps creating shlibs files out of symbols files at build time could
also be a solution for this.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100228125215.ga15...@pcpool00.mathematik.uni-freiburg.de
Re: Bug#470960: 6.7.8.2: point 4 (use foo-ver.orig for repacked tarballs) seems backwards
* Charles Plessy [100309 16:12]: > > This seems to be confusing. I think common practice is to > > append to the upstream version, either dfsg (if that's why > > you have repacked) or other tags depending on the reason. I > > think this point (4) should be dropped, and the > > version-tagging expanded. > > I just read #470960 and agree with Jon's comment. It is strange to signal that > a package is repacked by appending ‘.orig’ to the name of its top level > directory. I am not aware of any of our infrastructures that would rely on > this > string to detect repacking, I do not know anything that it checking this, but you run into this quite often, as dpkg-dev will generate a .orig.tar.gz if there is none but there is a .orig directory. (which sadly dh-make will create for you if you do not specify an orig tarball[1], resulting in far too many needlessly repackaged .orig.tar.gz in our archive). Hochachtungsvoll, Bernhard R. Link [1] It got a bit better, but still has that feature available by a flag and does not warn enough against its usage in my eyes. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309152420.ga31...@pcpool00.mathematik.uni-freiburg.de
Re: Priority dependence
* Russ Allbery [100718 19:30]:
> Ideally, it would be nice to be able to sort out packages by priority and,
> from that, build, say, a CD set of only the important and higher packages
> and know that it's self-contained. In practice, I suspect that we have
> enough packages with problems here that you have to compute the dependency
> closure anyway, but insofar as priorities are useful for anything, I think
> that was the goal.
Calculating a dependency closure is neither an easy nor an task with
a well-defined outcome. Starting with more data makes that both more
easy and more likely to come to deterministic results (with a good
enough starting set, most dependencies will most likely already be in
that set, so the likelyhood to encounter virtual packages or or-ed
dependencies (especially those were different packages have different
first choices) is much smaller.
The difference between optional and extra is indeed mood today. But I
guess that is mostly because dh_make is making everything optional
instead of extra by default...
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100719104154.ga6...@pcpool00.mathematik.uni-freiburg.de
Bug#590511: Document significance of first-listed alternative in dependencies
* Russ Allbery [100727 00:18]: > Policy currently doesn't directly document the default choice of the > first-listed alternative of a set of dependencies, which came up in > the discussion of Bug #587279. I believe Policy should state that, > if none of the alternative dependencies are currently installed, the > first listed alternative should be considered the default package to > install to resolve the dependency. > > We probably have to be careful how we word this to provide wiggle room > for package managers who may prefer to install the dependency that > requires the fewest additional packages be installed ([...]) I do not think it makes sense to tell the package manager what to do, especially as one would have to list too many exceptions anyway (like two packages get installed that have different package at the first position in an otherwise equal list of or'ed list). How about rather stating that the maintainer should order the list so that the first choice so that a user is commonly best advised to chose the earlier over later choices? (With some extra bla about buildd behaviour). Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100802180132.ga19...@pcpool00.mathematik.uni-freiburg.de
Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
* Russ Allbery [100827 19:27]:
> I'm torn on that bug. The ideal thing to do there, I think, is to say
> that lines consisting solely of spaces and tabs are a syntax error and are
> not allowed, but parsers may accept them as paragraph separators. (Be
> conservative in what you generate and liberal in what you accept.)
I'd rather see if it encourages parsers to error out in those cases
(Fail early, fail often). If something accepts them because they cannot
propagate the error properly that is no big problem. But if too many
allow them they will get used and there will definitly be code that has
problems because there is simply no way to test all those different
cases.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100827190148.ga3...@pcpool00.mathematik.uni-freiburg.de
Re: init script config files
On Fri, 7 Jul 2000, tony mancill wrote: > What if we did this? > /etc/rc.config.d/sendmail.default > /etc/rc.config.d/sendmail > (or /etc/rc.config.d/sendmail.override) > And so on. Always source sendmail.default first, so that we know we have > sane values. If "sendmail" is there, source it too. This way, users can > take a peek at the .default file to see what should in their file, and we > can add important variables at anytime because .default would come with > the package (but *not* be a conffile - users should never modify it). > Anything the user adds configures will be there, and remain there (until a > package purge?). What about a .../sendmail script, which is not a conffile, wich calls a .../sendmail.user to let it change variables? (I think it depends what users could want to change. ) And if any such thing is implemented, the not-conffile should have important comment saying it is not a conffile. (And a Sentence in policy that this file has to) Hochachtungsvoll, Bernhard R. Link
Re: reminder: menu icons should be 32x32 or smaller!
On Thu, 10 May 2001, Wolfgang Sourdeau wrote: > While we are on the subject, is the 24 colours palette really > mandatory ? If so, why since most of modern displays depth are at > least 8bpp? > > Icons with only 24 colours are just dirty when you have to adapt them > from beautiful 8bpp icons, while 8bpp icons are still acceptable when > they are made from 24bpp icons. > Please, keep it as few as possible. There are still enough systems with 8bpp. And when the whole 8bpp is used by the icons, it begins palatte-switsching, colour-guessing and many other ugly things. It becomes just a *pain* to use, if there is only *one* programm or *one* icon with too much colours. Hochachtungsvoll, Bernhard R. Link
Colons in upstream version.
While looking in policy and the implementing code I found a little discrepancy, I wanted to discuss: Policy 5.6.11 describes the upstream version part as: | The upstream_version may contain only alphanumerics[28] and | the characters . + - : (full stop, plus, hyphen, colon) | and should start with a digit. If there is no debian_revision | then hyphens are not allowed; if there is no epoch then | colons are not allowed. Quickly grepping over the indices of stable and unstable, the possibility of having colons in there is not used. Looking at the code, this is not very suprising, as the upstream version is included in several generated filenames, e.g. by dpkg-deb --build: # cat test/DEBIAN/control | Package: test | Version: 0:1:1.1 | Architecture: i386 | Maintainer: noone | Description: test | with colons in version number # dpkg-deb --build test . | dpkg-deb: building package `test' in `./test_1:1.1_i386.deb'. Which is not nice, as those would be escaped for http-requests, cause files with %3a in the apt-cache, and most propably rejected by jannifer, as dak seems to use (in utils.py) | re_taint_free = re.compile(r"^[-+~\.\w]+$"); to check filenames to be welformed and thus would reject such files, if I parsed the code correctly. Other programs reject colons in version number, e.g. dh_make checks the version number against '[0-9][0-9a-zA-Z+\.\-]*' Thus I suggest 5.6.11 to be changed so that colons are no longer allowed, and plan to file a wishlist-bug agsinst debian-policy, if noone contradicts. Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin) pgpKArjium9XK.pgp Description: PGP signature
Re: Colons in upstream version.
* Anthony Towns [031101 06:53]: > I'd be more inclined to fix the tools, personally, or to say that > "within Debian, we'll translate upstream colons to something else" > than removing the support from dpkg or changing its meaning. Sorry, I have problems parsing this. Does this mean you have nothing against debian-policy stating colons are not allowed (and how they should be translated) in upstream versions, as long dpkg can still cope with them for non-Debian packages? Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin)
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
* Santiago Vila <[EMAIL PROTECTED]> [031103 18:19]:
> What are the real benefits from having build-arch and build-indep?
> Are there really so many packages which would benefit from having them?
The real benefit is that it makes it possible to really use
Build-Indeps, that most multi-binary-packages need to build
arch-independent documentation only once. (Compiling XFree on
some small machine for example already hard enough a task, even
without the hour needed for installing all the build-dependencies
for the documentation...) Not to speak about easier bootstrapping
of new arches and such things...
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does not deserve
nor will he ever receive either. (Benjamin Franklin)
