> >Please provide a rationale. Some of my packages need a static ID (64000
> >is assigned, the only one assigned so far) because their spool could
> >need to be NFS shared.
static user id´s are a _problem_ with nfs, not a help.
that´s why this proposal is: if the user id is read via /etc/passwd
(o
> Yes, but they're configurable at build time, which is problematic if the
> uid/gid is already taken on the system on which they're installed.
changeing the user name will also affect
- setuid programs
- crontab files, cron.daily/monthly/weekly files
- inetd.conf entries
- some daemons have
> This is common enough... should we perhaps create a system wide file, that
> maps default {user,group}names to local {user,group}names?
>
> eg, in /etc/local_names:
> mysql mysql
> ups ups2
no, please do not add another level of indirection.
most daemons have configureable user id's anyway.
On Fri, Aug 27, 1999 at 01:39:38PM -0700, Joey Hess wrote:
> Active proposals
>
> Section 3.2 should not allow static user ids (except root=0) (#43483)
> * Under discussion.
> * Proposed by Andreas Jellinghau
> If I use static ids 0-99, they're set, both numbers and names. I can be
> sure, that on every debian system they're assigned the same (or
> unassigned, in case of older systems, and via dependencies I can force
> base-passwd to be updated) - stated in policy 3.2.
we should target compatibility t
On Wed, Aug 25, 1999 at 11:20:59AM -0500, Nathan E Norman wrote:
> On Wed, 25 Aug 1999, Andreas Jellinghaus wrote:
>
> : Package: debian-policy
> : Version: web page 1999-8-25
> :
> : Debian allows static user ids. This is not a good idea.
> : the code necessary
Package: debian-policy
Version: web page 1999-8-25
Debian allows static user ids. This is not a good idea.
the code necessary to use static id's is pretty small
(several versions on debian-devel 1999-8-25), so every
daemon should do so. this way its easy to use a package
on a non-debian linux whe
[kernel headers in /usr/include not matching current kernel]
yes, this generates problems for kernel dependend software like isdn,
knfsd and similiar stuff.
99% can be fixed by compiling with -I/path/to/current/kernel/linux/include.
only 99%, because any inclusion of linux/* and net/* will cause
> In Debian, running the postinst script _is_ configuring the package.
> If you want to install a package but not to configure it, use
> dpkg --unpack.
fix that user interface. lots of people will want to unpack a software, look
at the description, files, man pages, docs, and then decide whether t
> Qt does this too, but that's because we're not allowed to move it from
> /usr/local. I really think all these little compromises on policy are a bad
> thing because they cause problems like /usr/local symlinks being deleted.
> This is Very Not Acceptable.
second. i like to have no /usr/local a
please make apt the default install method in apt.
this helps a lot. btw: a multi-cdrom-install method is required.
hamm did not fit on one cdrom, slink will not, too.
and if kde is removed from debian, it would be better if they could provide an
extra cd (installable via apt) rather than createin
On Mon 14 Sep 1998, Francesco Potorti` wrote:
> I suggest that the policy makes clear that packages should add proper
> filter entries in /etc/printcap. For example, the package tetex-bin should
> add an fx entry in all printers in /etc/termcap.
i'm useing magicfilter. where is the advatage
Debian gnu/linux 2.0 m68k binary cdrom
you might want to add something like "build useing the official scripts with
own enhancements" or so.
but the name is "Debian gnu/linux 2.0 m68k binary cdrom",
without the word "official". of course you can add "brendlow's" or,
use a different name, as longs
On Sun 30 Aug 1998, Guy Maor wrote:
> By that reasoning all X11 binaries should be placed in /usr/X11R6 so
> that you can have different versions of them compiled with your
> different versions of X.
you have one gcc in /usr. and you can have any number of additional gcc's in
/usr/* like /usr/i486
On Sun 30 Aug 1998, Manoj Srivastava wrote:
> Not until you show me an upgrade path to R7 and X12. The
> current method allows for co-existance of several releases of X
> (barring our own bad /etc/X11 directory). Until an upgrade path, with
> an eye to the future, is available, we should c
> Such a move would, in fact, break section 4.1 of the FSSNTD,
> and would also violate the FHS.
agreed. why don't ask the fhs team why they left the link for this single
package ?
> This proposal also does not have an ewasy way of transitioning
> between releases of the X WIndow sy
> Also please check with the LSB (or whatever it is called today) guys
> before making such an incompatible change.
i agree, please check with fhs team and lsb team.
but it's not an incompatible change, as long as there are symlinks:
/usr/X11R6, /usr/{bin,libs,include}/X11
andreas
> Wouldn't bother me if we whacked /usr/X11R6 altogether and just moved all
> its stuff into the FHS-compliant places, and left behind the appropriate
> symlinks.
>
> I have no idea if/how this would break existing stuff, though.
i see no reason not why it should not work. the dirs under X11R6 pr
> I'd like to get a policy decision on whether /usr/X11R6 is for:
> a) the X11 system only
> b) the X11 system + all applications that depend upon it
i vote for
c) every package that is installed by default into X11
this way X11, fvwm and such stuff will go into X11R6, but tcl/tk, gnome, kde
i phoned with christian.
problem solved, will drop the virtual package names.
andreas
(maybe all debian developer should have a phone number, or better an
internet phoning service installed ? could reduce the telephon cost, and
helps to solve problems... (and is much faster than email))
> I thought that policy required discussion, not just notification.
thanks for telling me ! i looked at the policy :
... (using and not using virtual packages) ...
They must not use virtual package names (except privately, amongst a
cooperating group of packages) unless they have been agreed upon
> We are still supporting their packages in the sense
> that we support their installation. Should any package
> reference packages that aren't available in any of Debian's
> three distributions (main, non-free, contrib)?
people will install them with and without our support. we can make sure,
tha
> At the risk of starting another flamewar, providing a KDE
> package that installs in /opt is an obvious violation of debian
> policy, which I assume is why Andreas does his own. Although
> Andreas encourages us not to get the KDE people off-side,
> sometimes it wouldn't hurt if the KDE people wou
> I'm not entirely unserious here. I agree with Christian's earlier
> post; do we really need to go out of our way to support a
> non-debian-maintained package?
we don't support it. we make sure, that their packages will not brake
our packages, and vice versa. what is wrong with this ?
andreas
p
> Andreas, would dropping the Provides from my previous solution solve your
> problems?
then we would have some sort of a "we do nothing" case. yes, it would
work, but we had to rename our packages and conflict with their version
(i can't ask other to do stupid work, then i could do it myself - th
On Wed 26 Nov 1997, Bdale Garbee wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> : their packages are available, ours not...
>
> I think there are two things that I must have missed in the discussion on this
> topic:
>
> - why are there two sets of KDE packages? One should be suffi
> (For simplity and without loss of generality, I'm just describing the
> solution for kdebase and kdegraphics. Furthermore, the "Depends:" lines
> have been simplified.)
>
> The Debian packages:
> Package: kdelibs0g
>
> Package: kdebase
> Depends: kdelibs0g, ...
>
> Package: kdegraphics
>
> Won't our turning off --force-overwrite in 2.0 be a more realistic
> solution of this problem? Aren't most package conflicts really
> related to their usage of competing file structures? Or am I totally
> off-base here?
kde's version of kdelib is not compatible with my kdelib :
we have differe
short term solution
===
my solution (two virtual names) is meant to be a short term solution.
all i want is, to inform you and to give you the possibility to offer me
a better short term solution.
long term solution
==
anything that needs a policy discussion/findi
> I don't think anyone would call our distribution "broken" if he/she
> removes some of our packages, replaces them with someone else ones, and
> fails.
hey, it can also work the other direction.
their packages are available, ours not...
andreas
> As our packaging format becomes more popular (and we really want it,
> don't we?) there will be more upstream authors that package their
> programs as "deb" but don't follow our policies (non-FSSTND-compliant
> packages, for example).
>
> What are we going to do to avoid conflicts between their
> You might also want to contact Andreas Jellinghaus (maintainer of KDE
> packages). Perhaps he knows some tricks how to do this easily :-)
[about changeing paths ...]
oh : it's easy :
a) one large rules file, that moves everything to the right place
and
b) edit every single file, se
> No. We'll definitely not clutter our virtual package list just to support
> some outside group distributing replacment packages for ours.
>
> I suggest that you leave the kde* packages as they are now (have been
> before that change) so that they don't provide anything and that they
> suggest ea
> Surely it is sufficient for your packages to Conflicts: theirs
> and theirs to Conflicts: yours.
i need the provides: so i have something to conflicts: to.
> Also, should Conflicts: etc refer to packages outside the distribution,
> eg the KDE-done kde packages? Unless we are planning to distrib
i generate a .deb verion of kde, and kde does the same.
to seperate them, i use two packages :
a) debian-kde.deb-package
b) kde-kde.deb-package
all my packages provide: a), suggests: a) and conflicts: b)
please register these packages in the virtual package list.
andreas
by the way : how can a system admin configure /usr/bin/editor ?
the automatic system is fine, but maybe admin wants to choose
the default editor ?
andreas
> Some of this information should probably end up in the Policy docs, but
> I'll gladly leave that up to the folks on debian-policy.
>
> Any and all comments welcome,
a sysadmin should always have the possibility to control this.
because debian is getting more and more such features, we need
a do
sunsite.unc.edu/pub/Linux/doc/fsstnd (or so, should be easy to find).
should have the old and the new version of the fsstnd 1.0 1.1 1.2
and fhs 2.0 ...
andreas
--
Find out how to avoid all those pesky crashes, lockups, application
errors, and slow applications at http://www.debian.org -- Debian
what about this :
the new to-be 2.1 distribution should be empty (not all these symlinkls
to the old hamm tree), and only real new packages with fhs should go
there.
this will allow an easy way for most packages to update.
for complicated things like email, where all packages have to be
upgraded
[idea of a script, that moves everything to new places, doing lots of
symlinks].
not a good idea.
in the old slackware says, i moved my own system to fsstnd : moving
files around, sometimes using symlinks, sometimes recompiling things.
i will never try to do something similiar again.
to many prog
> Please don't get me wrong: I like the FHS! But we can't implement it for
> Debian 2.0 (hamm) and keep the current dead line.
so decide now : fhs or deadline, we cannot have both.
i think that libc6 will kill the deadline anyway, so i'm a friend of
fhs.
andreas
> > i will like an automatic method to close bugs.
>
> Let's take a look at the .changes files. Normally all information
> is covered there. Normally closed bugs are mentioned in the
> Changes: section. So Guys script should look for #(\d+) and
> close $1 after proceeding (speaking in Perl).
l
please split hamm into two distributions :
hamm/unstable and hamm-unstable/fhs-unstable (maybe you have better names).
we should have a good way to seperate new fhs compilant packages and old
fsstnd packages. having two distributions will make life easier,
and i don't think that it is a big deal.
two people throwing with mug to each other, but one of them complains
about the other throwing mug. please be quiet david.
i'm not a member of the bruce fan club, and i'm not as blind as some
other developers, but this time bruce is right. stop flameing him, stop
your mini revolution.
we will ha
> I only view disadvantages with this solution:
>
> a) users can't change the directory to their own
>documentations tree.
the documentation is provided on a per package basis, not on a per
language base. moste people will search documentation for package pkg,
and look if their language is a
On Sun 26 Oct 1997, Martin Schulze wrote:
> Andreas Jellinghaus writes:
>
> > > Topic 4: Announcing new packages before uploading them
> >
> > we should stop announcing and let a script on master do this.
>
> And according to James' oppionion this script
On Sat 25 Oct 1997, Ian Jackson wrote:
> What would be wrong with using update-alternatives to mantain
> /usr/bin/window-manager ? (Pointing to the binary itself or to a
> script which knows where to find the config file if the window manager
> is too stupid in its policies about where to find the
On Sat 25 Oct 1997, Ian Jackson wrote:
> Andreas Jellinghaus:
> > here is my tutorial of dsource, a 100% vaporware program.
> > [...]
>
> I would say `I like it', but then I'd lose my image as unfailingly
> critical. So instead I'll say `I have some qu
> This point was also adressed in Brian White's "Upcoming Debian Releases"
> document
> (http://www.debian.org/Lists-Archives/debian-devel-9709/msg00042.html).
>
> Could you please explain how you see the relation between that
> document and
> the "POLICY WEEKLY" messages? Is Brian's document obsel
here is my tutorial of dsource, a 100% vaporware program.
$ mkdir ~/debian# Choose where you want stuff
$ cd ~/debian # alternative "echo root=~/dir > ~/.dsource"
$ dsource-ftp get hello
Connecting to my.ftp.server.
Changing Diretory to /debian/dist/stable/main/so
On Thu 23 Oct 1997, Thomas Koenig wrote:
> My suggestion would be that daemons should be started up according to
> the runlevel the system currently is in. Interaction in postinst script
> should only be done when absolutely necessary, IMHO.
i don't like this idea. it is very usefull, for normal
> Please tell me where I am wrong.
your create complexity where there is none.
source handling works very fine for me, and i simply do not understand
why you add this complexity, like managing sources as root.
i only see the disadvantages.
so : please not show me example code, please show me a
On Thu 23 Oct 1997, Christian Schwarz wrote:
>
> Topic 13: Starting daemons in the postinst scripts
like my proposal to topic #12 :
if you want to query the admin, please recognize some special file or
variable "e.g. /etc/dpkg/fastconfig", do not start the daemon, and
add a line to a log file, s
> I'd prefer Joey's solution: xbase should install a script `install-wm' (or
> similar) which is called by all window manager's postinst scripts. The
> `install-wm' script will ask the sysadmin where to place the new wm (top
> or bottom of the file).
>
> Any other ideas?
a directory doesn't help
On Thu 23 Oct 1997, Christian Schwarz wrote:
>
> Topic 4: Announcing new packages before uploading them
we should stop announcing and let a script on master do this.
andreas
a) if someone looks for documentation, she changes the directory to
/usr/doc/, and looks what is in there. so people will not find
documentation in /usr/doc/LANG/
b) for one file a directory isn't necessary, in my opinion.
/usr/doc//. is ok for me.
locale should be the 2 char language code, or _,
On Wed 22 Oct 1997, Bruce Perens wrote:
> We recently had some conversation on rules of discourse for the mailing
> lists. At that time, discussion by most developers was strongly against
> them. Only myself and two other people spoke out for them at all.
>
> I want to check for opinions one more
i agree with christoph. some upstream maintainer hate you if you make a
small note about something, others are happy for any feedback.
i don't see how a policy can deal with this.
but of course i agree with you, bruce : we should first check, if the
problem is debian related, and not bother upstr
> Same thing here. Would it be possible to have a WWW-page on which all
> policy changes are logged? Something like:
>
> 1/1/93: All manpages should be compressed for policy 2.0.3.99
> 1/2/94: All packages should switch to the new source format, policy 2.1.2.3
> etc. etc.
>
> I would really appre
On Tue 30 Sep 1997, Yann Dirson wrote:
> FSSTND 1.2 defines the /usr/share/ directory, but not anything like
> /usr/local/share/. Does anybody knows whether it's normal ?
many people want to share /usr/share in large networks, even with
multiple architectures. nobody wants to share /usr/local/.
> /usr/bin/perl shall thus belong to an essential package.
can you replace essential packages with non essential ones ?
i'm not sure, at least removing essential is not possible without a
force option.
andreas
> The FHS is the sequel to the FSSTND, but it changes several different
> things (moves lots of documentation/man pages to /usr/share, moves mail
> to /var/mail). We're going to have to come up with a solution to this
> soonish.
so packages already designed to fit fhs are ok, or do i need to move
if we give /usr/X11R6 it's own hirarchy, why don't we do everything to
there ? and where should we stop ?
examples :
- /var knows no X11R6
- we have our doc files in /usr/doc, not in /usr/X11R6/doc
new fhs draft will make some things different :
/usr/share takes many files : doc, man, locale
On Tue 23 Sep 1997, Will Lowe wrote:
> On Wed, 24 Sep 1997, Andreas Jellinghaus wrote:
>
> > kde strcuture is nearly fhs draft compatible, but not fsstnd compatible :
> > /usr/share/doc and others. what should i do ? i don't know.
>
> Umm, as far as I can see, t
kde strcuture is nearly fhs draft compatible, but not fsstnd compatible :
/usr/share/doc and others. what should i do ? i don't know.
andreas
what is the current /usr/doc/standard ?
kde uses
default/(symlink to en)
LANG/ (two letter language code)
HTML/ (or other formats, kde uses only html).
PACKAGE/
PACKAGE.html (and other files)
i know that c
policy sais nothing. fsstnd and fhs draft are not exact.
current decission of our policy manager is to place all x11 programs and
their files in /usr/X11R6.
my opinion : /usr/X11* exists for historic reasons. the x11 system (in
our case xfree86) and related files (e.g. window manager) should go in
> The FSSTND says that /usr/X11R6 is for "X and related files". Our current
> interpretation to this is that all X related stuff (applications,
> includes, libraries, etc.) go under /usr/X11R6.
and i don't interpret it this way. in my interpretion, /usr/X11R6 exist
for historic reasons. so if a pa
> So please let us stop this discussion now and get back to something
> useful.
second !
(or write to me in direct email, no cc's to any mailing lists. i like
the discussion, but i heard nothing productive in the last mails.)
andreas
On Sat 20 Sep 1997, Manong Dibos wrote:
>
> On Sat, 20 Sep 1997, Christoph Lameter wrote:
> > >Sorry to bother debian-private with a discussion that belongs to
> > >debian-devel or debian-policy (I've set the Reply-To:), but I repeat
> > >myself saying that you should put all under /opt/kde and no
you are right. some years ago when i started learning linux, the biggest
difference to dos was, that files were not seperated by source package,
but by type. the only existing exceptions are either historic or have
good reasons (e.g. minimal root file system). /opt was never
designed because it's g
i think it's time for a general discussion :
where should debian place files ? /usr/local is local, so we should not
touch it. but there are several big packages, that could go into /opt.
current policy is the hardest way : everything in /usr, nothing in /opt.
we should discuss whether we want to
72 matches
Mail list logo
