> That would be a reason *not* to put it in policy, at least until we
> consider the reasons for such a refusal. Policy is supposed to
> encode the things we do agree on.
That's not true, and it never was. Policy changes often leaves existing
packages in non-compliance. And that's good.
As I s
> Comments, seconds anyone?
I second this.
> s> A better design would have been having the file to have a
> s> second UID/GID.
>
> s> So, a file could be owned by root, but setuid man.
>
> ACLs and capabilities are probably two very different solutions to
> this problem.
>
> (...depends on how they are implemented).
It's
> > Argh, egg on face: linux lets the owner of a file modify it even if it
> > is mode 444 and in a directory they do not own. Yuck! Is this standard
> > unix semantics? It sucks.
> Even worse: IIRC the owner of a file can chmod it to his or her
> heart's content, and this is standard Unix semantic
> Now I have another package baz, which I am also upstream for.
> a) I want to release baz to the whole world, not just debian, but I
> do not want to create a new package whenever a debian package change
> occurs
You could just release it to Debian, but not to sunsite. And you up
> Nicolás> Packaging it native is a perfectly valid thing to do, even
> Nicolás> better than nonnative. Why? Because the Debian packaging
> Nicolás> files can be used by anyone, not just Debian. Just as the
> Nicolás> .spec files are now included in many packages.
> But there is a tr
> > The idea of "if it's a bug in the software -> upstream, if it's Debian
> > packaging -> Debian BTS" it's wrong and users shouldn't be told that.
> Agreed. I don't advocate this.
> Do we really need a change of policy for this? And how do we handle
> cases where it is appropriate to encourage
> > No, all bugs should be reported to Debian ...
> I don't think that we should be in the business of telling anyone where
> they should submit their bug reports. If the user wishes to deal with
> the upstream developers directly, that is his or her prerogative.
Of course, but Debian has a way
> Native is best choosen for packages which are not expected to be used
> outside of Debian, btw. If I were xine's upstream, I'd package it as
> non-native. The non-native format is more flexible.
Packaging it native is a perfectly valid thing to do, even better than
nonnative. Why? Because the
> Users of Debian packages should be encouraged to file bug reports with the
> BTS directly unless they can be absolutely sure it is an upstream bug. How
> many of those users have the time and expertise to read/grep thousands of
> lines of source code and make such a decision?
No, all bugs shoul
> > The system in `bug' is mainly targeted too to custom made packages, of
> > multiple sources, not just the few well known huge makers of packages like
> > Helix (Ximian! =) ) or Corel.
>
> That makes is a strict subset of the features of the dpkg based
> approach, since that offers that as wel
> > What is the status of this proposal? Are we still undecided on its
> > merits or do we just lack patches to the policy and packaging manuals
> > to codify it?
>
> I'm still in favour of my proposal.
>
> > If we don't have consensus on this approach, maybe Nicolás'
> > implementation of the
> Okay, hopefully the final language change:
>
> Proposal is to change section 2.1.5 of the Debian policy to say:
>
>Non-free programs with cryptographic program code must be stored on
>the "non-us" server because of export restrictions of the U.S.
>
>Programs which use patented algo
> Since lintian reports the absence of a manpage as an error, maintainers
> (specially new maintainer) proceed to install a link pointing to
> undocumented.7 instead of actually providing a manpage. Before
> proposing to get rid of this, I'd like to hear opinions as to why we
> should allow t
> Ian> I don't think that using the changelog bug-closing mechanism is
> Ian> appropriate for when a bug is closed with no change to the code.
>
> Would you care to explain this statement? If closing the bug
> is indeed propoer, why shouldn't the changelog mechanism be used?
> Indeed, I
> 4. ftp-client: could be useful for packages like dftp which depend on
> ftp. This wouldn't include programs like ncftp, which are completely
> different, but rather ftp and heimdal-clients (which includes ftp).
Uhm.. but ncftp, lftp *are* ftp-clients... maybe "traditional-ftp-client"
should be
> My idea is that every DD's skills in should be recorded.
They are recorded in our minds. There's a reason people often use the word
community to describe free-software projects, and the reason is that you end
knowing a lot of people. And some names will sound good, because they'll
bring m
> The sorts of information which currently get displayed, but which don't
> get prompted for, are things like "Restarting internet superserver:
> inetd", or "Updating /etc/network/interfaces: succeeded".
>
> To me, those sorts of outputs seem useful and helpful, so I think policy
> should probably
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need this to declare a new reply in it's init
> > > script. It's very simple, I check your init script like thi
> >
> > E.g.:
> > objdump -T $( readlink -f /proc/$PID/exe ) | egrep 'symbol1|symbol2'
> >
> > The processes to restart could be taken from ps AND /etc/init.d/*.
>
> How would it know that it is a service as opposed to a running "ls" or
> cronjob? How would it know how to restart simple ex
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need this to declare a new reply in it's init
> > > script. It's very simple, I check your init script like thi
> > > Ok, I'm tired of having to track all services that might need to be
> > > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > > to require all packages that need this to declare a new reply in it's init
> > > script. It's very simple, I check your init script like thi
> Ok, I'm tired of having to track all services that might need to be
> restarted after a libc6 upgrade. So here's what I am going to do. I want
> to require all packages that need this to declare a new reply in it's init
> script. It's very simple, I check your init script like this:
Is it posib
> > > That would not be a logical step. Right now programs such as rlogin, ssh,
> > > NFS etc make sure that you cannot login as root or that root rights
> > > get smashed. If your box is cracked somehow, it often is the case that
> > > people can get any userid they like _except_ root. If the syst
> > It seems that in order to take full advantage of capabilities, files should
> >not be owned by root. Files should be owned by a non-login user (e.g. bin).
>
> That would not be a logical step. Right now programs such as rlogin, ssh,
> NFS etc make sure that you cannot login as root or that roo
> > Yes, you are right, I was probably too optimisitic with that. But, perhaps,
> > the "general change" will be the modification of EXT2 to support "resource
> > forks", but the needed changes in the VFS are probably small, and perhaps,
> > one of those new filesystems will include capabilities b
> > That's not true, capabilities can be handled with system calls. A daemon
> > may drop all capabilities except the one needed to bind to privileged ports.
> > But the daemon would still be ran with UID 0, and be able to modify/access
> > any root owned file in the system.
> Granted. Application
> > That's not true, capabilities can be handled with system calls. A daemon
> > may drop all capabilities except the one needed to bind to privileged ports.
> > But the daemon would still be ran with UID 0, and be able to modify/access
> > any root owned file in the system.
>
> Why wouldn't it a
> > It seems that in order to take full advantage of capabilities, files should
> > not be owned by root. Files should be owned by a non-login user (e.g. bin).
>
> I don't believe that is true at all. Can you explain why you think that
> would be advantageous?
>
> > That's because root will be
> Nicolás> That's because root will be just another user, with its set of
> Nicolás> capabilities, and you may like to prevent him from altering
> Nicolás> system files.
>
> Nicolás> As this is a major change, we'd better start now. This will
> Nicolás> also help people who want to implement
It seems that in order to take full advantage of capabilities, files should
not be owned by root. Files should be owned by a non-login user (e.g. bin).
Currently:
-rwxr-xr-x1 root root42300 jul 29 13:26 /bin/ls*
It should be:
-rwxr-xr-x1 bin bin 42300 jul 29
> Perhaps it just needs a better name? Security-History ? Exploits-Fixed ?
> I donno.
`Serial' is better because it's an opaque number. The other names you
propose imply false meanings.
BTW, this idea is great! I had propoed (several times) a
"Last-critical-version:" header to achieve the same e
> Those instructions are not in the policy manual, but at the end of the
> packaing
> manual.
Shouldn't this paragraph be removed? Is there any old source package left?
> >> At present, it's pretty random. I would like a consistent answer to make
> >> its way into policy, but there are lots of different cases, and I don't
> >> think a simple "foo-doc installs stuff into /usr/share/doc/foo" is the
> >> best answer. One must also consider that some doc package a
> > > What about the /usr/doc/foo
> > > symlink -- is foo-doc going to take care of that? What if I later
> > > install foo? Who gets to remove the link?
> > I don't know, but this kludge is a secondary thing, and should not be
> > considered when making policy. Any policy will last longer than th
> Nicolás, my one concern: lets assume a user installs both mutt and
> mutt-doc, and mutt-doc installs its docs into /usr/share/doc/mutt.
>
> User says to userself, "why is my /usr/share/doc so big?" A `du' later,
> and the mutt docs are the culprit. User thinks to userself, "bummer, I
> like mutt
> > Think this: Do the docs document the docs? /usr/share/doc/mutt documents
> > mutt, but /usr/share/doc/mutt-doc... documents... what? mutt-doc? Is a
> > nonsensical place for documentation, I think. It only has some sense from a
> > package management perspective, but that's not ok, package man
> > > 1. I subtly avoided those by specifying doc- rather than -doc :-)
> > > FWIW, I think we ought to come to agreement about the proper behaviour:
> > > right now I don't know *where* to look after installing foo-doc.
> >
> > Here the solution is clear to me. A package mutt-doc docume
> > That's a half true. Many packages install files in the doc directory of the
> > package being documented. /usr/share/doc/doc-rfc/ should only have a
> > changelog and a README.
>
> 1. I subtly avoided those by specifying doc- rather than -doc :-)
> FWIW, I think we ought to come to
> > > Except that a package named doc-rfc will already have files in
> > > /usr/share/doc/doc-rfc (copyright and so forth), and so having others in
> > > /usr/share/doc/rfc is a little weird and unexpected.
> >
> > For you. Not for me. And I can't think why it would be for the users.
>
> Becaus
> This is one of the most irritating things about DPKG and I hope it
> gets fixed soon. I would have put the severity even higher, but
> there's probably some policy behind that. :(
This problem would not exist if ldconfig could be given a parameter to tell
it which libraries it has to act on.
> > > > > On Sat, Apr 15, 2000 at 03:14:07AM +0300, Eray Ozkural wrote:
> > > /usr/share/rfc/
> > >
> > > Makes more sense to me. I don't see a problem with the package name.
> >
> > /usr/share/doc/rfc is much better. You don't need an rfc package for that.
> > Look at the doc-linux-html packag
> > > On Sat, Apr 15, 2000 at 03:14:07AM +0300, Eray Ozkural wrote:
> > > > > > The RFC docs currently reside under /usr/doc/doc-rfc. The second
> > > > > > doc is redundant, which is also part of the package name. It should
> > > > > > be fixed to be using /usr/share/doc/rfc
> > > > >
> > > > > Ar
> >I heartily agree with Daniel's plea. Eveb a simple listing of what
> >configuration files the package uses (and where they are), and where it
> >stores data (i.e., does it use space in /var) would be a big help.
> less /var/lib/dpkg/info/.list
>
> If you really care, write a nice wrapper
> Submit-Bugs-To-> Bugs-Submit-To
> Submit-Bugs-Style -> Bugs-Submit-Style
I don't think that's a good idea. Why do we need those fields in the
control fields? Do we put menu information there? Or doc-base info?
Bug-reporting is a separate issue from packaging. The `bug' tool allows for
p
> Well, in the mlgtk package i maintain, i have the Makefile gunzipping the
> needed file automatically, and make clean gziping them again. (i also have a
> make clean in the example dir during prerm, so dpkg will remove the correct
> files).
>
> I think something such as that is a good solution,
> --
> if a package contains examples that need to be compiled, they must be in such
> a state in the package that the user can just copy the directory to its home
> directory (or /tmp/ or wherever) and build the examples with no more hassle
> than typing ./c
> Looking for seconds.
I'll give you 60 if you just wait me a minute...
er.. I mean.. seconded.
> The following proposal tries to address cases like Bug #34294.
>
> \begin{proposal}
> Do not initialize a text database by using the conffile mechanism.
> \end{proposal}
>
> Rationale: We should try to reduce prompting to a minimum during upgrades.
> 99,999% users will always say "No" to dpkg p
What Santiago is doing is wrong. The whole point in of the transition being
done is never have to tell users "look there, or else: there".
In fact I remember that you, Santiago, were among the ones that made this
happen in the past blindly uploading packages in /usr/share/doc but with no
transi
> s> It's a bit complex, and requires modifications to every
> s> program that uses HTTP, but the modifications are simple, and
> s> it would be a nice thing to have. In most HTTP clients would
> s> be just adding a call to a function that sets the env vars
> s> according to t
> > I don't know much about debconf, but couldn't this variables stored in that
> > database?
> No, debconf is for install-time configuration, not run-time configuration,
> It is _not_ a registry.
`Install-time' you say, but still the data is preserved among different
`install-times'. So if you
> All programs must read proxy information from /etc/proxy (whatever
> format you want to make this, it could even be a base-like syntax for
> setting the http_* environment variables).
>
> However, if the defacto standard user environment variables
> have been configured, then these must be used
> Please stick to the merits of the proposal and don't speculate about my
> motivations. My only intent here is to avoid stamping a faulty design with the
> debian seal of approval by putting it in our policy.
>
> Having options that are only available from environment variables and not from
> con
> >> Http_proxy and web clients (#54524)
> > Nobody else want this? I thought we all agreed on this one...
> I'd like to see that in policy, but only if the programs use $no_proxy
> as well.
So you are sconding it.. aren't you? =)
> > Note that I'm not sure setting things in /etc/environment (or /etc/profile,
> > which is a worse idea) really works the way it should. does it override the
> > users' preferences saved in their dotfiles? That would be wrong.
>
> Oh yes -- thank goodness policy forbids such nastiness -- other l
> > > I don't think so - indeed policy says that packages shouldn't depend
> > > on environment variables for their correct behaviour(3.9). I don't
> > > disagree that http_proxy as an environment variable is common
> > > practice, but I do disagree strongly that this should be made policy -
> > >
> Http_proxy and web clients (#54524)
> * Under discussion.
> * Proposed by Nicolás Lichtmaier; seconded by Chris Lawrence and
> J.H.M. Dassen.
> * Requires that all web clients must honour the http_proxy
> environment variable, and that they should honour the ftp_p
> > I would expect that a mantainer have a little knowledge of his package. If
> > a binary is not meant to be called by the user, it is a bug to have it in
> > the PATH.
>
> Nicolas, this might show my naivite, but where should programs that aren't
> intended to be run by users go? I recall work
> > Writing your own undocumented manpage is just as bad.. typing man and
> > having to read something like `foobar has no manpage, type this and that and
> > don't bother me.' it's the same thing.
> > The manpage must provide some minimal information. That's what I'd propose.
> > e.g. The manpa
> > The manpage must provide some minimal information. That's what I'd propose.
> > e.g. The manpage must provide at least the information you can get from the
> > online help.
> That would give emacs, for example, one hell of a big manpage.
...the online help about command line options, of cou
> My main objection to undocumented(7) *is* that people treat it as a
> bug fix when use of it *is* still a bug! If we can convince people to
> start providing real man pages (even just quick-and-dirty ones that
> point to the real documentation, which is what I ended up creating),
> then I'll be
> a) the RIGHT way is more than 12 lines of perl code. "the right way" means
>that we wont have to do anything but add three small entries in a hash to
>allow other compression types. So you are incorrect on the size of this
>change.
>
> b) It is not just a matter of the dpkg tools, no
> > > > > The version of dpkg that I have in experiemental allows the use of
> > > > > bz2 for
> > > > > dpkg-source without breaking the format.
> > > >
> > > > Is there any reason for not having that bzip2 support in the potato
> > > > version?
> > >
> > > We don't want to introduce anything
> > > The version of dpkg that I have in experiemental allows the use of bz2 for
> > > dpkg-source without breaking the format.
> >
> > Is there any reason for not having that bzip2 support in the potato
> > version?
>
> We don't want to introduce anything like this into potato as part of dpkg,
> The version of dpkg that I have in experiemental allows the use of bz2 for
> dpkg-source without breaking the format.
Is there any reason for not having that bzip2 support in the potato
version?
> > Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> >
> > > You have a cost in being non-standard, and I don't think it is worth it
> > > this time. What benefits would give us what you propose?
> >
> > The cost is greater than /etc/ma
> > You have a cost in being non-standard, and I don't think it is worth it
> > this time. What benefits would give us what you propose?
>
> The cost is greater than /etc/mailname or /etc/papersize ?
>
> Debian long ago decided not to worry about the issue of being different and
> just build the
> > > I think your ideas may be suitable for wishlist bugs against packages
> > > that don't do what you want, but it shouldn't go into policy.
> >
> > No. The maintainers could close the wishlist without doing anything.
>
> I think that they would only do so if they have a good reason not
> > > Web clients should default to try to fetch URLs by a direct connection to
> > > the target host. If the `http_proxy' variable is defined, it should
> > > specify
> > > an URL that would be used as a proxy. Programs should not try to access an
> > > URL directly if this variable is defined. P
> > Web clients should default to try to fetch URLs by a direct connection to
> > the target host. If the `http_proxy' variable is defined, it should specify
> > an URL that would be used as a proxy. Programs should not try to access an
> > URL directly if this variable is defined. Programs that ha
> I propose that "woody" and subsequent releases permit the use of bzip2
> format for source packages.
I second this.
> > This is already standard, but I think it should be into policy because I
> > already saw some programs deviating from this expected behaviour.
> I'm not aware of netscrape doing this, for example. And it's better to
> use /etc/lynx.conf to make lynx do it too, as it prevents lusers
> forgetti
> > This is already standard, but I think it should be into policy because I
> > already saw some programs deviating from this expected behaviour.
> >
> > Web clients should default to try to fetch URLs by a direct connection to
> > the target host. If the `http_proxy' variable is defined, it shou
Package: debian-policy
This is already standard, but I think it should be into policy because I
already saw some programs deviating from this expected behaviour.
Web clients should default to try to fetch URLs by a direct connection to
the target host. If the `http_proxy' variable is defined, it
> > I actually think this is the wrong way round. We should really
> > arrange things so that the complete system is available on a server
> > somewhere, and then servers in countries that have onerous
> > restrictions should just avoid mirroring the bits they are not allowed
> > to carry. Unfort
> I thought about naming it 'crypto', but it would also not describe it
> correctly
> (since we also have packages encumbered by other silly laws there, like
> software patents). Any ideas?
legally-unsafe ?
country-sensitive ?
rebel ?
Wow, the `rebel' one is nice.
We would say: "Let's uplo
> > No I don't think that it's good idea. There's no point adding a bunch of
> > undocumented symlink to all missing man page for configuration file. :-)
> >
> > I agree that having a man page for the configuration file is good but I
> > don't want to force Debian developers to write man page for
> > > Having a manpage is a nicer and cleaner solution IMO. There's a whole
> > man
> > >section (5) for that.
> > >
> > > A sysadmin could delete the comments; he could choose to not upgrade the
> > >file (when asked by dpkg) and have incorrect docs.. but the manpage will
> > be
> >
> > Most configuration files have manpages, but not all. It would be useful
> >if every config file (intended to be edited) would be forced to be
> >documented in a manpage.
>
> Would it not be sufficient to require documentation either in a manpage
> or (as is often done) by comments in the
Package: debian-policy
Severity: wishlist
Version: 3.0.1.1
Most configuration files have manpages, but not all. It would be useful
if every config file (intended to be edited) would be forced to be
documented in a manpage.
> While everybody involved in this discussions sits and goes in circles, the
> rest of the project is going to pass -policy by and just impliment policy
> as it states in the policy manual and by the time the people who get to
> decide actually decide, it'll be harder to implement due to the number
> > Having a prerm script for a long time is a bad thing? a price too
> > high? come on!
>
> I've currently got 2112 files in my /var/lib/dpkg/rules directory. It
> takes 10-50 seconds to read that directory if it's not already cached.
> The situation will only get worse as new packages are added
> Nicolás> And this was handled pretty bad:
>
> Nicolás> 1) The update to the policy was obviously bad. It needed
> Nicolás>more discussion. Bad for the policy editors.
>
> What policy editors? There aren't any who have editorial
> power. And your comment is the reason why. Sorr
> Well you're flying in the face of years of tradition if you say that. It's
> true it's not written down anywhere, but that doesn't mean you can just
> disregard it. Saying that is making a _large_ change to debian's goals.
The only drawback of your proposal are estethical. And it has concrete
b
> > The policy was immature.
> Shouldn't the decision be undone for now, then?
Why do you think that we couldn't make a decision now? And will those
reasons go away in the future?
> > > I'm almost at the point that I'm ready to agree with the small and growing
> > > group of people who are saying screw the transition---the only thing it
> > > really hurts is /usr/doc/pac and being a creature of habit that
> > > annoys me. But I'd deal with it.
> >
> > I think this is the
> > IMHO, packages that
> > started using /usr/share/doc were premature in that usage
> Your opinion is wrong.
> Those packages follow current policy. Not using /usr/share/doc in a
> standards-version >= 3.0.0 package is a policy violation.
The policy was immature. And look at all the packages
> I'm almost at the point that I'm ready to agree with the small and growing
> group of people who are saying screw the transition---the only thing it
> really hurts is /usr/doc/pac and being a creature of habit that
> annoys me. But I'd deal with it.
I think this is the whole problem with this
> > I'd say that 95% of packages use debhelper or debmake.
> 75%. http://kitenet.net/programs/debhelper/stats/
> (A little out of date, hasn't been updated in a month, but it will soon..)
It should be higher... the more packages uses debstd/debhelper, the less
lines of code that need maintenainc
You don't care about the user. It seems that you just like to have your
distribution meeting many TLA standards and being the right distribution for
YOU.
The objections to this proposal were all to silly, too small.. too (arg! I
can't find a word... too.. picky?).
Is it about the potential co
Ups.. I haven't read the constitution yet... =)
May I second this proposal or I need a special hat? (I hope not a red one).
> > Create the symlink in post inst. dpkg need not be involved.
> Ah, but then this is not a simple one-line addition, as you said.
> For most of my packages, I have to change just one line in debian/rules
> to be FHS-compliant. With your proposal, the amount of work is not doubled
> by may
Programs which need to refer to all Debian docs should then still be
pointing to /usr/doc, until the migration is nearly complete. I'm talking
about apache ( /doc/ ), dhelp, etc.
> My idea (please note, this is only a first idea and there may be some
> difficulties with which should be fixed) is, that the new (FHS aware)
> debhelper could add something in postinst, which creates a symlink
> /usr/doc/ pointing to /usr/share/doc/ if (and only
> if) there is no special "flag"
On Mon, Jul 05, 1999 at 05:45:46PM +0200, Thomas Schoepf wrote:
> [Please CC me, I'm not subscribed to this list]
>
> I have a package that contains a README file with the program's history at
> the bottom. I've read the Policy about changelog files but afai can see
> this is a special case.
>
>
Why dpnt't we simply modify debhelper and similar tools to add this to
postinst of packages: (only if upgrading from a pre-FHS version)
if [ $1 = configure -a { $2 is a previous version than 1.2 } ]; then
ln -sf ../share/$package /usr/doc/$package
fi
And it would be just adding a
> The debian menus currently currently only exist in
> english, "en da's niet goed" (that's not good, Ott nem jó,
> Tio malbonas).
Mi opinas kio estas bonan ideo...
Nicolás>> Er... should I remove it from the manpages package? Should I
Nicolás>> wait? =)
Manoj> Removing it from the manpages package before policy changes
would be
Manoj> at least an important bug.
I know, I know... =)
> Can you provide any positive arguments in *favor* of undocumented(7)?
> We've been unable to find anyone who can justify it or explain why it
> was adopted as policy in the first place. But, of course, it *was*
> adopted as policy at some point, so surely someone must have had a
> reason, and ma
1 - 100 of 122 matches
Mail list logo
