Shouldn't we create with all this a `Linux registry' (sorry, but the
structure is very similar to the Windows one).
The `Linux registry' would be offered, through an API, to software
developers and other distributions, so there would be softeare enterely
configured with this registry.
It'd like to add this:
These scripts should not depend on having correct settings in the PATH
variable.
> > Shouldn't we create with all this a `Linux registry' (sorry, but the
> > structure is very similar to the Windows one).
> > The `Linux registry' would be offered, through an API, to software
> > developers and other distributions, so there would be softeare enterely
> > configured with this r
> Ian> Please explain to me what part of my proposal contained an embarassing
> Ian> kludge ?
> A symlink to be removed on a flag day, things mass copied
> over, and another symlink placed, is not a kludge?
All migarions I have `survived' in Linux used a similar approach:
The `cua0 ->
> sensible-editor will behave as needed by the current policy, but is
> more flexible. It could start xemacs on X and zile on console or do
> other additional checks. I think policy should state that programs
> should use sensible-editor as their editor.
I think we should extend policy by adding
Could sbdy explain me why?
Why would I need to share this static data among several machines? This
might mave been a concern when dskspace where a problem... Think that this
breaks the idea of a packaging system too.
And because this breaks the idea of a packaging system (the packaging
system i
> I have been using /usr/share for some time now in all my packages, including
> ones
> that were in the slink, release.
So?
> > > I have been using /usr/share for some time now in all my packages,
> > > including ones
> > > that were in the slink, release.
> > So?
> So it's nothing new...?
> I for one like /usr/share. Makes a hell of a lot more sense than /usr/lib for
> stuff
> like pixmaps nad hte like.
/usr/share
> Would it be possible to group menu items that would be together, just do not
> put them in the menu? So my menu would become:
>
> Apps>
> Games >
> Screen >
> System >
> Window Managers >
> Command Tool
> Shell Tool
> Xterm
But you would loose the alpha
> 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
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... =)
> 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...
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
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.
>
>
> 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"
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.
> > 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
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).
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
> > 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
> 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
> > 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
> > 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?
> 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
> 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
> > 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
> 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
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.
> > 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
> > > 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
> >
> > 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
> 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
> > 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
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
> > 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
> 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
> > 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
> > > 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
> > > 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
> > 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
> > 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
> 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?
> > > 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?
> > >
> > > We don't want to introduce anything
> 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
> 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
> > 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
> > 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
> > 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
> 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 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 -
> > >
> > 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
> >> 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? =)
> 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
> 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
> > 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
> 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
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
> 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
> Looking for seconds.
I'll give you 60 if you just wait me a minute...
er.. I mean.. seconded.
> --
> 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
> 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,
> 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
> >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
> > > 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
> > > > > 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
> 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.
> > > 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
> > 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
> > > 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
> > 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
> 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
> > > 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
> >> 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
> 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?
> 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
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
> 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).
>
> 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
> > 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
> > 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
> > 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
> > 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
> > > 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
> 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
> > > 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
> >
> > 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
> 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
> 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
> 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
> 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
> 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
> 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
> > 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
> > 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
> 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
1 - 100 of 122 matches
Mail list logo
