Bug#222779: Bug#161593: [PROPOSAL] definition of deb binary files
Previously Andreas Barth wrote: > IMHO this definition should become part of the policy; I propose > either an new chapter 12, or an addition to chapter 3 Binary packages, It should be part of the dpkg reference manual (partially online at www.dpkg.org). Patches against the text as you can find in CVS are welcome. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Previously Adam Heath wrote: > On Sat, 8 Nov 2003, Josip Rodin wrote: > > (FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some > > point.) > > I don't recall this. However, I could see mv debian deb. I said that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Re: Bug#185868: libpq.a not linked with kerberos libs
Previously Oliver Elphick wrote: > Why is this a bug? Surely you need to supply the krb5 static library > when you are linking your executable in the same way as you have linked > ssl and crypto. I should not, as I understand it, dynamically link krb5 > into libpq.a. If I statically link it, I will be including all of > libkrb5.a inside libpq.a, which also cannot be right. How do you expect upstream maintainers to handle static libraries? I can see three options: * provide a XXX-config tool that outputs the list of needed compile and link options. This is the approach taken by GNOME (and probably others) and works well. It means people using a library will automatically pick up the needed compile/link flags and will not find things suddenly breaking. * link everything into the static library and trust the linker to remove anything that will be duplicated in the final result. This is even easier to use than the previous option (no need to call XXX-config). * expect (upstream) maintainer to somehow know which libraries the static library on a system needs in order to link for every different platform the source is compiled with. Major pain whenever a distribution changes something in its libraries since it means all released soruces will suddenly break and more tests and rules need to be added. I don't consider the last option to be acceptable since it makes it very painful for maintainers to make sure their software will always work. I'm cc'ing this to debian-policy since it might be wise to come up with a policy on this topic. (note that I'm not subscribed there) Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: Versioned Symbols
Previously Stephen Frost wrote: > It's been done already in some places from my understanding > (libdb, libpng). The fix being hard to implement doesn't somehow make > the problem go away. libdb seems to have some evil hackery which puts a version string in symbol names, it doesn't use ELF versioned symbols. I don't see any evidence of version tricks in libpng3 sources. > I agree, which is why I feel the right thing to do is get versioned > symbols in our libraries. Versioned symbols is a lot of work and creates a maintenance headache for whoever maintains it. If you want to push those patches upstream it means that upstream authors suddenly will have a lot of extra work to fix a problem they are not responsible for at all. > It's been done. I don't doubt that it's difficult. Please do it yourself to see what it really involved. > I don't understand how this is supposted to work. The ssh-krb5 > maintainer builds against libssl0.9.6 and uploads. The openldap > maintainer builds ldap against 0.9.7 and uploads. Right, that is something you can only test after the uploads since it will be fine on each developers machines. It could be an extra check before something hits testing perhaps. > Hopefully this problem will be something we watch out for during a > release at least so we can avoid it there, and maybe even develop > scripts and whatnot to keep the problem from happening in testing. It is pretty easy to script a test for this one could run on an archive before a release. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: Versioned Symbols
Previously Stephen Frost wrote: > We need to make a decision on how to properly handle multiple library > versions ending up linked into the same process. I think what we should do is simple: 'do not do that'. > - Implement versioned symbols > - May cause binary compatibility issues > - Doesn't follow LSB (I believe..) > - Could be difficult to do correctly Very hard to implement and will result in non-trivial patches that upstream sources will probably never merge. > - Conflict between library versions > - Wouldn't allow valid setups where the versions aren't linked into > the same process > - Lots of packages would end up uninstallable for certain library > upgrades Those two reasons make it obvious we should not do that I think. > At the moment I tend to think versioning the symbols is the 'right' > thing to do and we should push to get upstream, other distros and LSB > to do that too. I don't think leaving things the way they are is > acceptable. I challenge you to implement it for a few versions of a few different non-trivial libraries. I think a different solution: check for this problem when build a package and abort if you hit it. That is trivial to implement as a linda check or standalone tool you can call from debian/rules. In fact I think dpkg-scanlibs already does that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Bug#99933: second attempt at more comprehensive unicode policy
Previously Colin Walters wrote: > Opinions? I second this proposal. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: Bug#174982: [PROPOSAL]: Debian changelogs should be UTF-8 encoded
Previously Colin Walters wrote: > #99933 goes a lot farther than #174982. First of all, we can't even > suggest that people use UTF-8 in package control fields until all our > tools support it. Right now it is just plain broken to put anything but > ASCII in them. Right. I'm tempted to make the next dpkg release abort if people try that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
Previously Mike Dresser wrote: > Isn't Packages compressed when apt-get downloads it? Looking at woody's > Packages.gz, it's compressed about 5:1, so I would expect this new > homepage tag to compress at least equally well, turning this into a 100kb > expansion. Depends on the dselect method I think, but the most popular one by far (apt) indeeds uses the compressed version. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
I did some quick math to see how much a Packages file will grow if we add a Homepage URL. The number of unique URLs currently being used: [tornado;~]-32> grep http: /var/lib/dpkg/available | sed -e 's/.*\(http:[^[:space:]]*\).*/\1/' | sort | uniq | wc -l 744 The amount of data currently used by URLs: [tornado;~]-33> grep http: /var/lib/dpkg/available | sed -e 's/.*\(http:[^[:space:]]*\).*/\1/' | sort | uniq | wc -c 25919 The total number of available packages: [tornado;~]-34> grep -c '^Package:' /var/lib/dpkg/available 11516 >From this data we can calculate the average size of a URL: 25919 / 744 = 34.837 characters. If we use the name "Homepage" as field name that means we will end up using 11516 * (10 + 34.837) = 516342.892 or approximately 504 kilobyte of data. As a result of this the Packages file will increase 516343 - 25919 = 490424 bytes, or around 479 kilobyte. That is a lot of data for people using modems. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
Previously Andrew Suffield wrote: > Well, why not? All it would take would be for > apt-ftparchive/dpkg-scanpackages to not copy the relevant fields into > the Packages file; would this break anything? (and if so, can we fix > it?) It will break all existing dselect methods for example that exepect all the data to be in the Packages files. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
Previously Adam DiCarlo wrote: > Well, before I venture on this, is there a way we can store certain > data in control.tar.gz or something but without bloating the Packages > file? No. > This does feel like a debian-devel or debian-project issue rather than > a policy issue, too...? It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author & homepage information as well? Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
Previously Adam DiCarlo wrote: > Comments desired. Perhaps it makes sense to think about all fields people would possible want. The rpm format for example has a license field. Is that something that people would like to see for deb as well? I'ld rather make all such changes at once. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
Previously Josip Rodin wrote: > Scenario: we start using XK- now, then wait for it to become common > practice, dpkg gets changed to support , all those packages that have > XK- need another change to s/XK-//. Not necessarily need, the XK field would still work but there would just be a new preferred way of setting that data. Tools that parse this data will not notice the difference. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: [PROPOSAL] Drop 30000-59999 uid/gid reservation
Previously Joey Hess wrote: > Well my proposed wording also recycles it, it just lets us get bits of > it back from the admin in extreme circumstances. In extreme circumstances we can always ask the admin no matter what policy says. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [PROPOSAL] Drop 30000-59999 uid/gid reservation
Previously Andreas Schuldei wrote: > actually, the idrange from 6-64999 could be used by joey, > too, if we redifined it properly. it could say something like > 'only on debian project owned machines'. (i understand the > description of that id range to apply to those boxes, no reason > to clog it up on other machines.). I suspect Joey is talking about mooix, which anyone is free to install. We certainly won't install it on debian owned machiens though :) Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [PROPOSAL] Drop 30000-59999 uid/gid reservation
Previously Joey Hess wrote: > What if we change the "Reserved" for 3-5 to "Reserved for use > at local admin's discretion", and then something like my package can > just ask[1] if it's ok to use a set in that range; an admin who is using it > for something else like a large NIS or whatever can nix that request. I would prefer not to do that, but if that is the only way to get people to second the proposal I will agree. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [PROPOSAL] Drop 30000-59999 uid/gid reservation
Previously Joey Hess wrote: > Well, I have a package that really needs a minumum of 100 but ideally > 1000 semi-static uids of its own (the block should be contiguous; must > have _no_ user in the password file for at least a large percentage of > them; don't ask), but I have not dared to bring it up on policy. Scary, why would it need so many uids? At the moment we have a bit under 5000 free entries in the static system allocation range (6-64999) and we still have 65000 up to 65533 reserved, so we are not short on space. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
[PROPOSAL] Drop 30000-59999 uid/gid reservation
Package: debian-policy Severity: wishlist We have reserved the 3-5 uid/gid range for ages, but never used it and observing the current rate of growth I don't think it makes sense to keep them reserved: Debian will not use that range in the next century, while large systems definitely can use the extra room. Also, we should add a reservation for 2^64-1 for systems with 64 bit uid/gids. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Processed: reassigning back...
reassign 159744 debian-policy thanks Folks, please get a consensus and stop this stupid reassigning and closing/reopening. The bug was cloned and one of the clones is assigned to dpkg-dev already, so reassigning this one does not make sense at all. Policy still documents a relation that is not ready for use yet and has never been announced as such by the people implementing it (ie the dpkg developers). If you decide that you want people to use a half implemented feature that might change behaviour again, feel free to close this bugreport and forget about it. I'll happily reassign bugreports about people running into problems with Enhances back to debian-policy later in that case. If you decide to remove references to Enhances from debian-policy, great. It means people won't be tempted to use something that isn't quite ready for general use yet. But at least make a decision and stick with it instead of this silly reassigning/opening/closing. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#127809: dpkg doesn't know about Enhances: - yes it does
Previously Matthew Palmer wrote: > Are you contesting 'support' or 'sane'? Both. > >From dpkg-1.10.6/ChangeLog: > > * dselect/pkgdepcon.cc: treat enhances like suggests in > packagelist::resolvedepcon() That's only 15% of the changes that need to be made. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#127809: dpkg doesn't know about Enhances: - yes it does
Previously Matthew Palmer wrote: > Since 1.10 is now out and about and (AFAICT) has sane support for Enhances, > I would suggest that this bug be considered closed. No, it doesn't. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains "debug"
Previously Marcus Brinkmann wrote: > As for me personally, I have made peace with -O2 code. stepi is your friend > ;) Fwiw, debugging C++ code using STL with -O2 is almost impossible. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
Previously Chris Waters wrote: > If the merely-functional virtual packages were actually useless (which > is essentially what you said), then I think we would be justified in > throwing them out. But I don't think they are, so I don't think we > are. Ok. I think we are actually all in agreement now, Can someone please volunteer to go through the list of virtual packages and document them properly? For each virtual package we should document * a description of what it should be used for * a complete description of the interface packages should provide if that is relevant for that virtual package Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
Previously Mark Brown wrote: > You also need to know which command to invoke and you need to know when > it's safe to discard any temporary file you might be pointing at. The same holds for editor which does have a well defined interface. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
Previously Moshe Zadka wrote:
> www-browser: definitely, here a standard interface (give a URL on the command
> line) is useful. currently, urlview depends on an ugly hack
> to do that (listing browsers itself)
doc-central does the same thing.
> mail-reader: honestly, I fail to see a reason why this is sane.
> "less /var/mail/moshez" is as good a mail reader as any.
> what on earth would prompt someone to suggest a mail-reader
> is truly beyond me.
Mail notification programs what start a MUA when you click on them
for example.
> Should a mail-reader also be able to *send* mail? That would actually
> make it a useful virtual package, again with a minimum of interface
> (accept an address on the command line, e.g.)
The name mail-reader suggests it doesn't. Perhapt it would be useful
to introduce mail-user-agent, which is both a common name, unlike
mail-reader, and has a proper definition:
mail user agent
(MUA) The program that allows the user to compose
and read {electronic mail} messages. The MUA provides the
interface between the user and the {Message Transfer Agent}.
Outgoing mail is eventually handed over to an MTA for delivery
while the incoming messages are picked up from where the MTA
left it (although MUA's running on single-user machines may
pick up mail using {POP}).
> Better: adding interfaces for those virtual packages which lack an interface,
> and supplying patches to support those interfaces, and throwing
> those which truly serve no purpose.
Definitely.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
Previously Chris Waters wrote: > Some virtual packages (mail-transport-agent, c-compiler, httpd, most > of *-server) clearly do have an associated interface. Some > (mail-reader, www-browser, audio-mixer) clearly do not. Lack of an interface tends to be troublesome. Look at doc-central for example: it has to guess which web browser you have installed. Other programs will have the exact same problem. In this case the interface is really minimal (how does one start a browser), but the lack of a well defined interface is problematic. > If that were true, then nothing would depend on mail-reader or > www-browser or audio-mixer. But things do. And things could be better if they could actually start a mail-reader automatically :) Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
Previously Moshe Zadka wrote: > Ummm.if a C compiler doesn't support a /usr/bin/cc which supports -o > and -c, it shouldn't "Provide: c-compiler" A virtual package is a means to indicate a package provides a certain interface, not some functionality. Functionality is useless if you can't use it in a standard way. If a random package X can not rely on and use expected behaviour by random package Y that provides a virtual package Z without hardcoding specific on Z we might as well ditch the concept of virtual packages. For MTAs the standard interface is /usr/sbin/sendmail with a couple of standard commandline options (LSB has a nice list). For a C compiler the interface is /usr/bin/cc with a few common options (which definitely include -c and -o). If policy is currently unclear on this we should improve the policy text. It definitely makes sense for each virtual package to specify the exact interface it represents. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make it official
Previously Matt Zimmerman wrote: > The only possible issue that I can see is that the introduction of this > virtual package would leave no way to depend specifically on the ISC DHCP > client 2.x, which is currently named dhcp-client. You could take advantage of the fact that dpkg doesn't support versioned virtual packges at the moment and use a versioned dependency to make sure you get the real dhcp-client. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rewriting policy soonish if poss.
Previously Julian Gilbey wrote: > I know that Manoj has been talking about moving to the DocBook DTD for > the next version of policy. What are people's experiences with it? I use DocBook for all documents and manpages now and it works great. > How does it compare to the DebianDoc DTD for what we are likely to > want to do? Could we easily create a "rationale" tag that is > selectively (or even non-selectively) processed? I don't see why not. You can create your own stylesheet and add a rational thing in there, or use something like XSLT to add customized tags in your document and convert them into proper docbook when needed. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#152955: debian-policy: section 10.3.2 in force-reload should be more clear
Previously Henrique de Moraes Holschuh wrote: > Oh, quite the opposite. It is *desirable* to have force-reload defined as > "force a full configuration reload of the service, if it is running. Fail > otherwise". But the code to do so is more complicated. I don't see that begin complicated, the --test option for start-stop-daemon should be everything you need. > What should be done if the service supports the reload, but is not running? Nothing IMNSHO. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149709: BUG] section 10.3.3 does not provide enough guidance for package maintainers to use update-rc.d correctly
Previously Branden Robinson wrote: > 2) The examples advise people to redirect the output of update-rc.d to > /dev/null. Adam Heath and I feel this is a bad idea, and even if this > change is not made, some people (like the author of lintian; see Bug > #149700) think that this is normative. To me the example looks > informative, not normative, as it would be inappropriate to put the > example text into an ELF maintainer "script" or a perl script. I agree. if update-rc.d is too chatty for use in a maintainer script it either needs to be more silent and a verbose option added, or a new option for silent running needs to be added. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for change : base-passwd userids
Previously Josip Rodin wrote: > I thought it would do all necessary changes after you said "Yes" on the > prompt. It does, but the logic to decide which changes are necessary can handle options like that (and a few others). Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for change : base-passwd userids
Previously Jor-el wrote: > I have seen indications that this is contrary to debian-policy - hence > my request for revision. I'll look into revising things on the next base-passwd rewrite which will be sometime this year. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for change : base-passwd userids
Previously Josip Rodin wrote: > Therein lies the reason why they cannot be simply removed. If you happen to > install a new base-passwd and have it redo the group file, all the existing > software on the machine that uses them may break. I suspect you are not aware of the no-autoremove feature base-passwd has had for some time now :) Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Objection to change made in debian policy
Previously Adam Heath wrote: > Or, even simpler: > > %: > debian/myrules $@ The unfortunate problem with this is that make has the nasty habit of changing the exitcode. If myrules exits with a non-zero exitcode you will see make exiting with a completely different (although still non-zero) exitcode. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Objection to change made in debian policy
Package: debian-policy In version 1.23 of the policy.sgml file Manoj made a few changes that were related to incorporating the packaging manual into policy. Since the packaging manual did not have policy status this should not have changed anything in policy, certainly not without a clear consensus. The change I am objecting to is this bit: + + This file must be an executable makefile, and contains the + package-specific recipes for compiling the package and + building binary package(s) out of the source. + There never was a consensus that debian/rules has to be a makefile. This was discussed but the only consensus that was reached was that policy should dictate the interface to debian/rules. I suggest we either try to get a consensus on this, or downgrade the must to a recommendation. Personally I increasingly feel that make is not the right format for debian/rules. rules files are getting more complex with and expressing all the needed commands in make is becoming increasingly awkward. For this reason I want to have the freedom to use another method (a sh script), which is perfectly possible with the documented interface to debian/rules, except for this requirement that silently slipped into the policy document. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148172: command -v in postinsts violating policy
Previously Clint Adams wrote: > Is this important in the event that install-docs gets moved, or so that > someone can put a different install-docs in the PATH? Both. Making things more fragile is always a Bad Idea. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148172: command -v in postinsts violating policy
Previously Clint Adams wrote: > > Such as? > > test -x /usr/sbin/install-docs || echo hi That's different and more fragile: it relies on a fixed path which command -v does not. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy ambiguity regarding control files
Previously Richard Braakman wrote: > I still find it useful to grep and sed the Packages file. I don't > see any advantage in allowing multi-line fields that would compensate > for that. FWIW, dpkg does allow it. Debian policy is free to not allow it of course. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
Previously Anthony Towns wrote: > I can assure you I had a lot less time to do stuff like fiddle with the > BTS when I was trying to get potato released. And I can assure you I was doing a lot more work on new things while still working on the potato release than I am doing now. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
Previously Anthony Towns wrote: > On Mon, May 06, 2002 at 07:17:12PM +0200, Marcus Brinkmann wrote: > > Debian development is asynchronous. > > That's a nice idea in theory. It just to be true before we had testing. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: init.d scripts and LSB
Previously Jeroen Dekkers wrote: > Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and > Debian *BSD should follow the LSB. This is a discussion we should be having after the release on a forum like debian-project. FWIW, I think we should try to use the LSB as much as possible on all Debian ports. Please note the name: `port'. It is a port of the Debian system to the Linux, Hurd or BSD kernel. We want to have the same Debian everywhere instead of suddenly finding ourselves confroned with a fork within Debian. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: init.d scripts and LSB
Previously Grant Bowman wrote: > As I've argued late last year [1] Debian should take the necessary > Policy steps to move forward with LSB adoption. I agree, but I would like to add we should wait until woody is released. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
Previously Grant Bowman wrote: > This is somewhat an aside, but this is already moving away from > GNU/Debian Linux specific through several ports of GNU/Debian. There > are the hurd, bsd and win32/cygwin ports already. I have never been able to find patches for the win32/cygwin port though. I know the BSD folks have some patches that should be merged but those are partly stalled since we need to rethink dpkg's architecture handling. dpkg also runs on Solaris, HP-UX and IRIX. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
Previously Manoj Srivastava wrote: > On the other hand, all packages must not be left to the whimsy > of the dpkg developers either; since potentially large numbers of > packages would be impacted by such changes. I do hope you trust is to make changes sensibly. In fact the current reference draft already has some information on the backward and forward compatibility guarantees dpkg gives. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
Previously Julian Gilbey wrote: > Surely either everything necessary should be in the dpkg reference or > everything necessary should be in policy. I'm not sure. I see them more as complementing each other, much like RFC1855 (netiquette) complements RFC822 (email format) or how a users manual complements a reference manual. > I understand that dpkg can be used elsewhere than Debian, but > it's de facto purpose is to serve as the Debian packaging system. I'm somewhat interested in having dpkg accepted in other environments as well and gradually moving away from it being just the packaging system for Debian. > So if the dpkg reference doesn't document everything that Debian needs > in this respect, what is the best thing to do? dpkg allows things that Debian does not. Version numbering for NMUs is a good example of a policy that Debian adds on top of what dpkg provides. There will be a reference manual for dpkg that documents only dpkg specifics. You are free to copy parts of that into Debian policy, but I would rather have them as seperate documents. That means people will need to read both, but that might give them a better understanding of how Debian is build. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
Previously Julian Gilbey wrote: > Part I: The Debian Archive > 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) non-us is a different archive. > Part II: Packages and metadata Refer to a dpkg reference instead and document extra restrictions Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#96597: changing policy requirements for debian native packages to _MUST_
Previously Andres Salomon wrote: > The exact quote from the current policy is: > "If the package has only one changelog which is used both as the Debian > changelog and the upstream one because there is no separate upstream > maintainer then that changelog should usually be installed as > /usr/share/doc/package/changelog.gz; I like the fact that this is optional. The way I do this for my packages is by using a changelog for changes to the code, and changelog.Debian for changes to the packaging. This works nicely: all the intiminate details can be found in the changelog for those who need it, and the less interesting summaries and debian-specifics are in changelog.Debian for those who prefer a more brief list. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: New virtual package foomatic-data
Previously Manfred Wassmann wrote: > I proposed the virtual package foomatic-data on debian-devel on > 2001-12-11 and filed the bug #123570 against the debian-policy > package. There have been no objections against my proposal, so I > consider it to be accepted. This sounds like it is only going to be used by a small set of packages so this should not be in policy at all but just arranged amongst the package maintainers themselves. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Summary of KDE filesystem discussion
Previously Jarno Elonen wrote: > * Many people feel that KDE (and Gnome) is too large >a whole to be stuffed in /usr/bin, /usr/share etc >and would deserve a separate directory like X Define many. I also don't see what the advantage would be of moving it to a seperate directory. Without knowing what the actual problem is I don't see a reason for making any changes. > * Some proposed using /opt/kde3. Arguments: > >+ Other distributions work like this, and better > compatibility with them could be beneficial Incorrect, other distributions do not work like this. >+ FSH seems to permit this (possible > misunderstandings about phrase 'add-on package' > in it)... FHS does not allow it, /opt is for third party software which KDE and GNOME are not if the distribution contains them. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#129375: debian-policy: typo/logic error in debconf spec
Package: debian-policy Version: 3.5.6.0 Severity: normal In the description of the communication commands the current text says: * PURGE Call this in your postinst when your package is purged. It removes all templates and questions your package has generated. postinst should be replaxed with postrm there. Wichert. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux tornado 2.4.16 #1 Thu Dec 6 23:55:15 CET 2001 i686 Locale: LANG=en_GB, LC_CTYPE= Versions of packages debian-policy depends on: ii fileutils 4.1-9 GNU file management utilities.
Bug#128868: debian-policy: Depends semantics unclear re circular depends
Previously Peter Moulder wrote: > Please re-read the above paragraph. No-one has claimed that a circular > dependency is needed. That's the whole reason for this discussion though.. > They are allowed by dpkg, whereas current policy says that they are not > allowed, hence giving false confidence that no cycles will occur and thus > that one's Depends line will always be honoured wrt ordering of > configuration, which may turn out not to be guaranteed if a cycle exists, > even if no such cycle exists at the time one releases one's package. dpkg specifics and policy will also differ. dpkg is more then just an implementation of parts of Debian policy and at points will support more then policy allows. > There are many examples of pairs (A,B) such that: > - A is a package. > - B is a package. > - In order for A to be usefully be used at time T by users on a given > system S, B must be in an installed & configured state on S. > - It doesn't matter whether A is configured before B, or B is > configured before A. Right. This is the most common case I suspect. Now we could support this in dpkg, but: * that would mean adding yet another package relation type and people already seem to have difficulty enough handling the current set properly * it would only be really useful for a really small set of packages in Debian So the questions becomes: is it really worth it to add this? Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#128868: debian-policy: Depends semantics unclear re circular depends
Previously Peter Moulder wrote: > The thread begins at > http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg01329.html > where someone says it would be useful if he could ensure that a > particular pair of packages' postinst scripts run in a particular order. I'm not convinced the circular dependency is needed here, and in fact the current package does not have one. > Adam Heath voices what is I believe the natural reading of current > policy, namely that Depends implies postinst ordering, and consequently > that dependency cycles aren't allowed. Well, they are allowed but as soon as you create a cycle it will have to be broken so you can't assume an exact ordering anymore. > There are many cases where a package A requires other packages B in order > for A to run, but where A does not need B to be configured before A is > configured. How common? I'm not quite convinced it is common. Also a lot of those cases can be rewritten to use Conflicts instead of Depends. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#106280: debian-policy: There should be a note on devfs
Previously Anthony DeRobertis wrote: > The quoted version of policy says that the package must call MAKEDEV. As > long as this section is being changed, we should probably note that on > devfs systems, MAKEDEV will turn itself into a no-op. Why? Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: LSB Status
Previously Anthony Towns wrote: > Things break. That's what happen when things fail. You'll notice we don't > guarantee anything better for our own init scripts. LSB does so we will need to start caring. You can't selectively implement the LSB, that would make the whole thing worthless. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: LSB Status
Previously Anthony Towns wrote: > This doesn't need to be done for Debian packages at all (LSB init script > dependencies that interact with vendor scripts can all be trivially > satisfied by doing all the vendor scripts first), and the dependencies > for the LSB scripts can be resolved at package install time without major > difficulty. Which is to say, this could be supported without changes to > sysvinit or file-rc [0], without major difficulty. Not true, consider what happens for example when something fails. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: LSB Status
Previously Sean 'Shaleh' Perry wrote: > we can support the installation of lsb binaries HOWEVER the lsb spec adds a > 'status' option to init scripts which lsb packages may expect to exist. So at > the bare minimum we need to support that. At the bare minimum we'll need to support dependencies for init scripts which means we need to modify most of our own init scripts as well as update sysvinit to provide the necessary infrastructure. SuSE already has some of that which we can probably use. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [vhost-base] Draft policy proposal
Previously Daniel Stone wrote: > Oh, and also bear one thing in mind: the virtual host name (e.g. "foobar" > in /var/vhosts/foobar) may not have any correlation to the hostname, > domain, or whatever. So, please don't assume it does. /var is the wrong place for this. There is a push to move FHS to /srv but not specify what you should put in there which might be a better option. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Non-C/C++/ObjC source files in /usr/include subdirectories
Previously Matthew Palmer wrote:
> There is precedent (kind of), g++ uses /usr/include/g++, so why not
> /usr/include/{gnat|ada}?
c++ is a a C derivative, and the FHS explicitly limits /usr/include
to C. If you want to change the FHS bring this up on the fhs-discuss
list first.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Non-C/C++/ObjC source files in /usr/include subdirectories
Previously Florian Weimer wrote: > What about the Ada case? GNAT pretty much requires that complete > source code is present for all compilation units at compilation (and > binding/linking) time. And package specs are very similar to C header > files, at least with the GNAT compilation model. Quoting from section 4.3 of the FHS 2.1: 4.3 /usr/include : Directory for standard include files. This is where all of the system's general-use include files for the C and C++ programming languages should be placed. How about using /usr/share/ada instead? Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Non-C/C++/ObjC source files in /usr/include subdirectories
Previously Florian Weimer wrote: > Is it acceptable to put source files for non-C-related languages > (such as Python, Perl, Ada, Java, and so on) in subdirectories > under /usr/include? I'ld say no. Those languages don't use include files, they use libraries. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#32263: Proposal: Splitting cgi-bin
Previously Brian White wrote: > I realize that. Any idea when the patch I provide will actually be applied > to the policy manual? It would be nice to get this underway. After the woody release I suspect. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#32263: Proposal: Splitting cgi-bin
Previously Brian White wrote: > Any idea when the patch I provided will actually be applied to the policy > manual? It would be nice to get this underway. Thanks! Policy is frozen. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Technical Committee / Policy mailing list
Previously Ian Jackson wrote: > I'd appreciate it if people wouldn't send messages which are copied to > *both* the policy list and the technical committee. Actually the ctte list has seen 1 post this month, all the others never make it there since the list is moderated. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#115312: PROPOSAL make cgi-bin applications non-executable by default.
Previously Anthony Towns wrote: > This is daft. Packages should be functional as soon as they're installed, not > be fundamentally broken and require administrator action. Agreed. > Permissions aren't maintained over upgrades, so this will result in > further breakage dpkg-statoverride. >. And CGI applications with security issues shouldn't be packaged. Agreed. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [agiorgio@us.ibm.com: Excessive size of s390 vim binary]
Previously Gerhard Tonn wrote: > He is not talking about Linux, but a certain flavor of UNIX that is running > on top of z/OS formerly called OS/390 formerly called MVS. D'oh, should have noticed that :( Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
[agiorgio@us.ibm.com: Excessive size of s390 vim binary]
I just got this on the vim-dev list. If this is indeed so (strip does not work on s390) does that mean Debian policy forces us to have large unstripped binaries on s390? Wichert. - Forwarded message from Anthony Giorgio <[EMAIL PROTECTED]> - From: "Anthony Giorgio" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Excessive size of s390 vim binary Date: Wed, 19 Sep 2001 10:37:56 -0400 When vim is built on an IBM s390 mainframe, the size of the binary is much larger than it needs to be. This is due to the symbolics information remaining within the binary, since it is compiled with the -g flag. On a standard Unix/Linux system this is fine, as one can strip(1) a binary to remove the debugging info. On an s390 system, strip is identical to touch(1), and cannot remove the symbols from the file. Here's an excerpt from the strip man page: | strip -- Remove unnecessary information from an executable file Format strip file | Description | On some UNIX systems, strip removes debug information from an executable. | On z/OS, the debug information can only be removed by recompiling. strip | does not modify the contents of any executable file--it is functionally | equivalent to touch file. We should change the default behavior of the Makefile to not generate the debugging information. I propose that the makefile on s390 be altered to remove the -g flag from CFLAGS. Replacing -g with -0 (zero) dramtically reduces the size of the binary. It shrinks from 5853184 bytes to 2052096 bytes, a 65% reduction. What do you all say? On a different note, any optimizations I turn on (-1 or -2) for the compiler causes vim to commit a segmentation violation as soon as it is invoked. Anthony Giorgio DBX Developer Phone: (845) 435-9115 Tie Line: 295-9115 Email: [EMAIL PROTECTED] - End forwarded message - -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#112090: PROPOSAL]: support reduced footprint debs at build time
Previously David Kimdon wrote: > FWIW that is one thing that e2fsprogs-bf does. But that has a specific purpose, boot floppies. In the general case you have no idea what kind of usage you will get. > I wish a non-invasive approach would solve the problem. However I don't > think we will arrive at the space savings we are looking for. I don't think we can know that now. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#112090: PROPOSAL]: support reduced footprint debs at build time
Previously Richard Braakman wrote: > - Specific compiler flags (-Os?) That one would make sense > - Turning off compile-time options for rarely used features That's going to be highly controversial > - No documentation (not even the copyright file?) > - Installing most-popular subsets of installed data (example: terminfo, > keyboard definitions) > - Finer grained splitting of binary packages (this could subsume the > previous point) It does, and can be implemented by a possible dpkg feature where dpkg can optionally not install bits of a package, which looks like a much better approach. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#112090: PROPOSAL]: support reduced footprint debs at build time
Previously David Kimdon wrote: > The purpose of this change is to give Debian a more elegant way of > handling reduced footprint debs. Rather than including > special-purpose binaries in the archive (the status quo), I suggest we > support hooks in source packages that produce size optimized versions. Euhm, you serious expect the installer to be able to compile itself during an install? Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#109182: Removing more historical cruft
Previously Cesar Eduardo Barros wrote: > This proposal was not about traceroute. It was about everything else > (ifconfig, > route, mke2fs, e2fsck, etc -- everything a normal user runs and yet are at > sbin). The traceroute thing was just a footnote. A normal user who runs ifconfig, route or mkfs? That's about as likely as the pope suddenly switching to budaism. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: packages without .md5sums file?
Previously Marcus Brinkmann wrote: > Can you elaborate on the advantage of letting everyone generate their own > checksums for the installed files? Seems to me a waste of cpu cycles. We process all the data in a pipe anyway so calculating the checksum takes no effort. Benefits are we don't need to store them on lots of mirrors (space saving), it's more configurable (specify which checksums you want), it's more flexible (easily add new checksums without changing the archive). Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#106826: Mandate 64-bit file support for file utilities
Previously Florian Weimer wrote: > Wouldn't it be nice if each general file management tool > (command line or text-based or graphical file manager) > supports 64 bit files (with 64 bit inode values or size > greater than 2 GB) even on 32 bit architectures? Sure. Just recompile them with glibc2.2 and you're done (provided they are coded correctly). Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: packages without .md5sums file?
Previously Massimo Dal Zotto wrote: > Is this allowed by policy? Yes. > And if not should we change the policy and require that every package have > the .md5sums file? No. .md5sums are the wrong approach for this. The right approach is a combination of signing packages themselves, and dpkg generating (multiple) checksums on the fly when installing a packages. The signing part is implemented already, the second is not currently. I'ld much rather wait until that is implemented (which also won't require any policy changes) then decide on an imperfect temporary solution. (And yes, we are working on implementing that). Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#100472: PROPOSAL] allowing '-' between libraryname and soversion
Previously Enrique Zanardi wrote: > Current practice suggests hyphen instead of dot for including a version > in a package name: mico-2.3.0, kernel-image-2.2.17, cpp-2.95, perl-5.005, > netscape-smotif-475, libgnat-3.13p-1, libbz2-1.0, libid3-3.7-13, ... > just to name a few. Hm, I should have read the full proposal I guess :( Some of the mentioned package names in the proposal are quite bogus though: * libgtrans-mysql-3-23 Looks like a library for mysql3.23, not version 3-23 or so. Proper package name should then be libgtrans-mysql3.23 * libgtrans-postgresql-6-5-3 Same as above, should be libgtrans-postgresql6.5.3 * libid3-3.7-13 * libmath3d-0.3-0 I don't see where those numbers come from or why they are useful. The idea of seperating the ABI version (bit more general then soname) from the packagename with a - is indeed useful. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#100472: PROPOSAL] allowing '-' between libraryname and soversion
Previously Enrique Zanardi wrote: > On Mon, Jun 11, 2001 at 03:40:29AM +0200, Andreas Bombe wrote: > > Policy wants shared libraries to be in packages of names like libfoo6 > > for a libfoo.so.6. However this becomes confusing if the library name > > ends in a number so that the soversion is separated with a hyphen from > > the library name. Why not just use a dot instead of a hyphen? Makes much more sense to me. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#105753: debian-policy: missing reference to dh-make-perl in perl-policy
Previously Loic Dachary wrote: > I propose that the perl policy includes at least a chapter or > section titled dh-make-perl so that the existence of this tool is > obvious just by reading the table of content. I disagree, policy and tools are seperate things and should not be mixed. You are free to write a perl packaging tutorial though which does cover dh-make-perl. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: calling MAKEDEV from postinst
Previously Mike A. Harris wrote: > We currently AFAIR have all device nodes in a single RPM package > in RHL, however this may change.. You indeed do. > Does dpkg et al. have something similar, and if not, would it be > considered something useful? I can try to get/provide details if > it would be helpful. No we don't, and I consider it bloat in the package manager. We can already have devices inside a package iirc, and creating them in the postinst is a better approach. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#102204: PROPOSAL] Downgrade emacs/tex to optional
Previously Anthony Towns wrote: > --- policy.sgml Fri Jun 1 19:40:16 2001 > +++ policy.sgml.emacstexMon Jun 25 20:58:25 2001 > @@ -764,10 +764,7 @@ > These packages provide a reasonably small but not too > limited character-mode system. This is what will be > installed by default if the user doesn't select anything > - else. It doesn't include many large applications, but > - it does include Emacs (this is more of a piece of > - infrastructure than an application) and a reasonable > - subset of TeX and LaTeX. > + else. It doesn't include many large applications. > > optional > seconded. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#100586: PROPOSAL] Upstream patches should be separated from Debian ones.
Previously David Martinez CSIC RedIRIS wrote: > Well, I'd propose to make an addition to Policy and/or NM Guide: I propose to ignore this until Adam unveils the dpkg-source he is working on which will make this point moot. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#100346: PROPOSAL] Do not mandate existence of shared libraries
Previously Herbert Xu wrote: > Florian Weimer <[EMAIL PROTECTED]> wrote: > > and neither is libc6 because some parts of it can only be linked > > statically. > > Which ones? nss modules come to mind. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: obsolete information in debian-policy 3.5.5.0
Previously Jaldhar H. Vyas wrote: > However according to /usr/lib/dpkg/parsechangelog/debian, the acceptable > values for urgency are: And that list isn't correct either iirc. > This change seems to have happened around dpkg 1.9 but isn't in the > changelog. That's because that list was never the list that was used in policy. The list that testing uses is different from both. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: obsolete information in debian-policy 3.5.5.0
Previously Julian Gilbey wrote: > Wichert, Anthony, any chance of resolving this one soon? For what value of `soon'? Given that noone has noticed that even though this inconsistency has been there for years means it's not very high on my todo-list. We'll get around to it before a 1.10 release though. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: obsolete information in debian-policy 3.5.5.0
Previously Julian Gilbey wrote: > This inconsistency has only been relevant since testing came into > being. Which is months ago now and still nobody noticed, probably since the priorities for testing were never documented. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Is it allowed to remove old changelog entries?
Previously Adrian Bunk wrote: > It seems he's right and I can't find a place in the policy that forbids > the deletion of old changelog entries or did I miss something? It also doesn't allow it. Common behaviour seems to be to move the old changelog entries in a seperate file. Old changelog entries can be very useful at times as well, both to track down bugs or to find other historic data (for example I've been looking for old strace changelogs to see when I actually became a Debian developer but unfortunately they seem to have been lost :( ) Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: 7.5.1 Overwriting files in other packages
Previously Julian Gilbey wrote: > The CVS version no longer has the part "though currently ..." as this > is not currently true. That default will never change in the dpkg code anymore as well, instead the installer will have to put that in /etc/dpkg/dpkg.cfg. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: "Defaults for satisfying dependencies - ordering" gone?
Previously Manoj Srivastava wrote: > Well, 4.5 years is a long time, but I suspect that > sensible-editor mechanism was supposed to be the way to go. Since > packages already manipulate the sensible editor link, and there > always is supposed to be one, perhaps t was thought that editor > virtual package was redundant? According to the debianutils changelog sensible-editor was added in August 1997, that's a fair amount later. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: "Defaults for satisfying dependencies - ordering" gone?
Previously Josip Rodin wrote: > Well, because it's useless? A vast majority of packages depend on an editor, > anyway. I don't see why it's useless. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: "Defaults for satisfying dependencies - ordering" gone?
Previously Josip Rodin wrote: > 25 Nov 1996 Removed editor (should have done this a long time ago) Does anyone remember the rationale for that? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Shared libs vs. plugins.
Previously Daniel Kobras wrote: > For now I added a lintian overrides for this, but Sean asked me to bring up > discussion here to clarify what lintian should treat as shared lib in the > future in order to properly solve this issue. Geez, again? Basically a .so files that is not in /lib, /usr/lib, /usr/X11R6/lib or another directory listed in /etc/ld.so.conf is not a library (the dynamic linker can't find it anyway then) . Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Proposed solution to config.{sub,guess} issues
Previously Henrique M Holschuh wrote:
> The package diverts the outdated files /usr/share/automake/config.
> {guess,sub} and /usr/share/libtool/config.{guess,sub}, and supplies
> up-to-date files from CVS (there is a 2001-04-20 update supporting sparcv9b
> for example) in their place.
I doubt that is a good idea, it would be much nicer to coordinate this
with the libtool and automake package maintainers and get them
to depend on the new package.
> An debhelper helper script, dh_autotools is also provided. If a call to
> dh_autotools is added at the beginning of the "clean" target of
> debian/rules, it updates existing config.guess/sub files in the source
> package to the newest ones provided by autotools-dev.
Somehow I'm not sure if that is a very good idea. Then again, I never
use debhelper so I won't notice anyway :)
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Policy rewrite: chaps 11-13
Previously Julian Gilbey wrote: > 11.2, penultimate paragraph reads: > Packages that use libtool to create shared libraries should > include the _.la_ files in the _-dev_ packages, with the > exception that if the package relies on libtool's _libltdl_ > library, in which case the .la files must go in the run-time > library package. >>>This<<< is a good idea in general, and > especially for static linking issues. > > What does the indicated "This" refer to -- that packages should > include the .la files in the -dev or run-time package? -dev > 11.7.5 What does the following mean? > > However, programs that require dotfiles in order to operate > sensibly (dotfiles that they do not create themselves > automatically, that is) are a bad thing, and programs should be > configured by the Debian default installation as close to normal > as possible. > > (It's the last part I don't understand.) It should be a seperate sentence, indicating maintainers should put all kinds of non-standard stuff in default configuration files. > > If you need a statically allocated id, you must ask for a user or > group id from the base system maintainer, and must not release > the package until you have been allocated one. There is no `base system maintainer', that should be the `base-passwd maintainer' instead. > been allocated one you must make the package depend on a version > of the base system with the id present in `/etc/passwd' or Again, s/base system/base-passwd/ > 12.2 The last para reads: > > If a package wants to install an example entry into > `/etc/inetd.conf', the entry must be preceded with exactly one > hash character (`#'). Such lines are treated as `commented out > by user' by the `update-inetd' script and are not changed or > activated during a package updates. > > This isn't very meaningful as it stands. Makes perfect sense to me.. > 12.6 "Mailboxes are generally [mode] 660 user.mail unless the user has > chosen otherwise." > Should this be "unless the system administrator has chosen > otherwise."? Yes. > 12.6 All MTA packages must include a newaliases program, so there > should be a para reminding that all MTAs must Provide, Conflict > and Replace mail-transport-agent. I'm not quite sure why newaliases is obgliatory, exim doesn't need it for example. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#90989: proposal] making all control fields multi-line
Previously Cyrille Chepelov wrote: > Dependencies and Build-Dependencies can be quite long, which means either > using a lot of horizontal scrolling, or violating the policy (since lintian > checks for single-lineness of some fields but not those, and dpkg is happy > with that, and the buildds too, it's easy to forget that it's not allowed). This is a completely bogus argument: all fields are logically one line, although they can be split over multiple lines in transport. Please read RFC822 for all the details. Frontends shouldn't force one to do horizontal scrolling, they should do proper wrapping of the data when displaying it. > It would make sense to allow the relationship fields to be multi-line; It would make sense only since we use RFC822 syntax, which allows for fields to be split over multiple lines. > Requiring tools to accept multi-line values everywhere should help keeping > them simpler (actually, a lot of them already seem to do this, anyway). This should be through due to the simple guideline `be strict in what you output, but liberal in what you accept'. > Proposed changes: > [in section 3.1, Syntax of control fields] Please always submit proposed changes as a diff to the sgml text. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [control] continuation lines on relation fields ?
Previously Cyrille Chepelov wrote: > I think it would be very useful if DebPol section 3.2 began with an > informative table of all fields which can happen in a debian/control file, > with links to the relevant (normative) section for details, a very short > description of the kind of data I already did that for the dpkg reference manual actually. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: [control] continuation lines on relation fields ?
Previously Cyrille Chepelov wrote: > I've got an interpretation problem: can relationship fields be written > on multiple lines ? Looking at the dpkg parsing code, yes. Which makes sense, considering we are dealing with RFC822 syntax. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Policy rewrite: chaps 7-10
Previously Julian Gilbey wrote: > Agreed. I presume that ldconfig exists on all systems, though. All systems Debian currently runs on anyway. I kind of expect that to change at some point though. > Please explain; I don't know what you mean here. I'll have to get back to you on that :) > Are we going to follow the LSB for runlevels? Is there anything else > we should be following it for? This should definitely be a separate > proposal. I certainly hope we are going to follow it: Debian is in an excellent position to be a demonstration LSB complient system, and I would hate to miss that opportunity. LSB isn't finished yet though, and I expect more changes to changes to be needed at some point. People interesting in policy should definitely try to keep up with LSB as well > But it makes no sense to force-reload or stop or restart checkfs.sh. > What about /etc/rcS.d/S40networking? Or /etc/rc[2-5].d/S99rmnologin? > These two cases show that it's pretty close, but not quite all the way > there. networking should move out of rcS.d, since LSB specifies runlevels without networking which is impossible of networking is in /etc/rcS.d . > But should force-reload be a "must"? I would say so. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#89473: PROPOSAL] dpkg-statoverride and Conflicts: suidmanager (<< 0.50)
Previously Anthony Towns wrote: > Seems like either fakeroot could be enhanced to handle that, or maybe > such packages should be restricted to being built with sudo with the > appropriate checks in debian/rules to ensure that either the user already > exists, or that running adduser in debian/rules succeeds. You are missing the point. fakeroot can't handle this, unless you want it to intercept all attempts to modify /etc/passwd & /etc/group as well. We need to know the name, not the uid/gid. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Policy rewrite: chaps 7-10
Previously Julian Gilbey wrote: > But what does it mean for a "suggests to take effect"? (Pre-)Depends, Conflicts and Replaces are the only ones that dpkg cares about, the others are for frontends like dselect. A Suggests can't really take affect. > > > > 7.2 Depends: should also mention "or if it is required by the > > > postinst, prerm or postrm scripts". > > > > Remove postrm from there, that can't rely on the Depends being present. > > So we should say that somewhere; it's probably important: > The postrm must not depend on any non-essential package. non-essential is wrong wording, it can't rely on packages one Depends on to be present (same Pre-Depends) while it is called for "purge". It can rely on them being present during a "remove". > > > 7.5.1 States: > > > In the future `dpkg' will discard files which would overwrite those > > > from an already installed package which declares that it replaces > > > the > > > package being installed. This is so that you can install an older > > > version of a package without problems. > > > Has this now happened? > That's what the text currently says, taken straight from the old > packaging manual, AFAIK. Differences in interpretation, consider that the packaging manual was never written to be a policy document. `will' here was meant to indicate that dpkg will always do that, not that it will do that at some point in the future. > Agreed, so we should say something about this, perhaps only in a > footnote. I would rather that we remove the mention of ld.so and just say `dynamic linker'. That is accurate and flexible. The specific filename for the dynamic linker is an implementation detail. > > > 10.1.2: Surely directories should be removed by postrm, not prerm? > > > (Prerm may not always be called, eg if a package disappears.) > > > > Either might happen. > > What do you mean? Maybe I wasn't clear. The text suggests that > directories in /usr/local must not be in the .deb, but must be created > in the postinst and removed in the prerm; I asked why the prerm and > not the postrm. Actually, there is a reason: the postrm may not be > called if there's an error-unwind situation. > > Which is better to do: prerm, postrm or leave it up to the maintainer? prerm so we can handle error-recovery quicker. > > 10.3.1: needs to be rewritten for LSB complience which defines > > specific runlevels. > > OK, if you can give some pointers or details, that would be good. I would need to check, basically the LSB defines runlevels: * single users * multi user with network * multi user with network and X etc. I don't remember the specifics from memory, but you should be able to find those in the LSB documents (see http://www.linux-base.org/). > > > 10.3.2: Hard question: > > > Not all of start, stop, restart etc. are relevant for everything > > > in /etc/init.d, for example checkfs.sh. We should figure out a > > > way of distinguishing between daemons (which should accept all of > > > these) and specific startup/shutdown scripts (which needn't). > > > > Daemon or non-daemon is a really bad measure. > > Fine. Do you have any ideas of what the measure should be? I don't. > I just know we need one. I don't think we need a measure. I want to be able to force-reload my network config for example, to flush out bad firewall and routing entries. If we really need to have some distiction I would use /etc/rcS.d versus /etc/rc[2-6].d scripts. > > I don't think force-relead must be supported, restart already does > > the same thing. The other three should be a must though. > > OK. I gave this some more thought and decided that force-reload does make sense: reloading is a very different thing from restarting, but if a service doesn't support it we don't want to try a restart after a reload failed. For this reason a force-reload is useful. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#89473: PROPOSAL] dpkg-statoverride and Conflicts: suidmanager (<< 0.50)
Previously Anthony Towns wrote: > What's special about dynamic u/gids? You just make sure the user/group > exists in the preinst, then let dpkg unpack it to the correct id. No need > for statoverrides at all. The name of the user/group must be used in the data.tar.gz, which can only happen if the package is build on a system that has that group. That might not be possible with autobuilders. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Policy rewrite: chaps 7-10
Previously Julian Gilbey wrote: > 7.2 Binary dependencies > This section states that "All but Pre-Depends and Conflicts take > effect only when a package is to be configured." But actually, > dpkg appears to ignore everything except for (Pre-)Depends, > (sometimes) Recommends and Conflicts. So what should this say? It should say what it currently says. > 7.2 Depends: should also mention "or if it is required by the > postinst, prerm or postrm scripts". Remove postrm from there, that can't rely on the Depends being present. > 7.5 States: > Virtual packages (Section 7.4, `Virtual packages - `Provides'') are > not considered when looking at a `Replaces' field - the packages > declared as being replaced must be mentioned by their real names. > But does it in a Provides/Conflicts/Replaces scenario, as > described in 7.5.2? P/C/R is really a special case. > 7.5.1 States: > In the future `dpkg' will discard files which would overwrite those > from an already installed package which declares that it replaces the > package being installed. This is so that you can install an older > version of a package without problems. > Has this now happened? What do you mean? This has always been true. > > Chapter 9 > Should mention that ld.so might actually be ld-linux.so or > something else instead. It could be anything basically, especially if you start thinking about Debian GNU/HURD or BSD versions. > 9.2.2 Should say what dpkg-shlibdeps actually does if we're going to > say anything at all. The footnote should be zapped and the merged into the real text. What it says won't be entirely correct either once I replace dpkg-shlibdeps with the python versions. > 9.2.* Do we need /etc/dpkg/shlibs.default any longer? Yes. > 10.1.2: Surely directories should be removed by postrm, not prerm? > (Prerm may not always be called, eg if a package disappears.) Either might happen. 10.3.1: needs to be rewritten for LSB complience which defines specific runlevels. > 10.3.2: Hard question: > Not all of start, stop, restart etc. are relevant for everything > in /etc/init.d, for example checkfs.sh. We should figure out a > way of distinguishing between daemons (which should accept all of > these) and specific startup/shutdown scripts (which needn't). Daemon or non-daemon is a really bad measure. > 10.3.2: Should "The start, stop, restart and force-reload options > should be supported" be replaced by "must be supported", > contingent on the above suggestion? I don't think force-relead must be supported, restart already does the same thing. The other three should be a must though. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
