Hi,
I was examining other's java packages searching for ideas when I noticed
that this package has sources, but they are not used to produce the
binary package; a precompiled stuff, also included in the original
package, is copyed into the binary.
That's it.
I felt this was a grave omission, and I
On Tue, Nov 30, 1999 at 11:33:41PM -0800, Daniel Quinlan wrote:
> liblockdev seems like a really good idea, which we're considering
> adding to LSB (although the library function names may get changed
> along the way so they all have the same prefix).
lockdev_1.0.0_i386.changes just uploaded with
On Wed, Apr 14, 1999 at 05:23:20PM +1000, Hamish Moffatt wrote:
> On Mon, Apr 12, 1999 at 06:59:51PM -0700, Joseph Carter wrote:
> > I generally prefer not to have /floppy and /cdrom personally. I place
> > these under /mnt/floppy, /mnt/cdrom, /mnt/zip, etc. It seems to me that
> > /mnt is more a
On Wed, Apr 14, 1999 at 04:48:39AM -0700, Joseph Carter wrote:
> On Wed, Apr 14, 1999 at 03:02:11AM +0200, Wichert Akkerman wrote:
> >
> > Well personally I really disklike to have mountpoints under /mnt..
> > so, do we have the next battle after /var/spool/mail versus /var/mail ?
>
> It's unreas
On Mon, Apr 05, 1999 at 03:46:09PM +0200, Santiago Vila wrote:
>
> First, we should forbid the use of the hardcoded install-info's --infodir
> option in all maintainer scripts. This is really evil, because it does not
> allow us to change the location of the index file in a centralized place,
> i.
On Mon, Mar 22, 1999 at 10:39:27PM -0800, Darren O. Benham wrote:
> Just what is "official" Debain policy?
>
> "Everyone" says we want to switch to FHS.
> There are issues concerning the FHS.
> I'm setting up new packages.
>
> Am I supposed to use the FHS that "we want to switch to" or the FS
.
Forcing third party to install under /opt will not avoid name clashes
between third parties packages, but will surely avoid clashes with
Debian packages.
The system I proposed (to have postinst install symlinks and/or wrappers
from /opt packages) can permit to circumvent such clashes.
[EMAIL PROTE
Buddha Buck wrote:
>
> Is there any particular reason (besides history and inertia) that
> non-free and contrip packages aren't installed into /opt?
No, these two are quite strong enough :-)
Jokes apart, I have already proposed this (for non-free only), but I was
hit by the prevention that people
On Thu, Jun 04, 1998 at 11:16:29PM +0200, Gregor Hoffleit wrote:
> How do I handle version numbers if there are two concurrent branches
> of a package, one in frozen and one in unstable ? Say I have
> package_1-2 in frozen and package_1-3 in unstable. Now if I have to
> release a small bug fix for
On Mon, May 11, 1998 at 04:16:00AM -0300, Adam P. Harris wrote:
>
> This (trimmed) output from pkg-deps has me a little concerned about
> the policy compliance from Section 4.5 of policy:
>
> | All Debian MUAs and MTAs have to use the maillock and mailunlock
> | functions provided by the liblockf
On 8 Jan, Guy Maor wrote:
> Fabrizio Polacco <[EMAIL PROTECTED]> writes:
>
>> I recently managed to add some sources in my -dbg shared lib packages,
>> to make them easily debuggable. (See bug#16038 on 30 Dec)
>
> I rather liked your solution to the problem of deb
As I've seen bugs raised against packages that added the g _after_ the
soname in the package name instead than _between_ the name and the
soname, I ask:
- didn't we agree that would be better to add the "g" after the
soname like lib0g instead than libg0, to avoid confusion with
lib names alrea
Manoj Srivastava wrote:
>
> All right, I think I a beginning to agree. Maybe dpkg *should
> have integrity checking (as well as permission and ownership being
> recorded record [in the .list file maybe?] -- like a ls -al listing)
I am always annoyed by having dpkg -c and dpkg -L use a d
Christian Schwarz wrote:
>
> In the last policy weekly (#4), I asked for comments if we should
> make it policy that every package has to use liblockdev to lock
> devices. Noone objected so far.
>
> So, is liblockdev ready for a wide use or are there any (hidden)
> problems?
The library has matu
Hamish Moffatt wrote:
>
> 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 h
Ian Jackson wrote:
>
> I am here, honest.
>
> [... symlinks work ...]
>
a)
> The best first thing to do is probably to make a version of base-files
> that has links from the _new_ names to the _old_ ones, once we decide
> what things we're going to change and how.
>
> Then packages can start
Andreas Jellinghaus wrote:
>
> 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.
I don't see the connection between the ftp site and the file system on
user's machine.
Symlin
Andreas Jellinghaus wrote:
>
> [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 tr
Manoj Srivastava wrote:
>
> Technically, there is one right solution; and that is to use
> the keywords capability of the Debian changelog format.
Right. As I said, it's a polite design. I simply wasn't aware that the
"reserved for future use" was already implemented in the code, and not
Manoj Srivastava wrote:
>
> Charles> foo (1.0-2) unstable; urgency=low, closes=10002 11930 10109
>
> Right you are. In his infinite wisdom, the designer (Ian?) has already
> considered the possibility of multipe keyword value pairs.
I have to agree that this design seems much far better than th
Santiago Vila Doncel wrote:
> On 29 Oct 1997, Manoj Srivastava wrote:
> > Surely we can come to a consensus on something this trivial?
>
> foo (1.0-2) unstable; urgency=low; closes=10002,11930,10109
>
> seems fine to me (using ";" after "=low").
Surely this is far from being trivial.
That
Manoj Srivastava wrote:
>
> In balance, I think I prefer changing the changelog syntax to
> include closed=, though it raises the spectre of modifying
> changelog.el and dpkg-parsechangelog.
>
Why? That syntax should be interpreted by the installer's scripts on
master, not on the maint
Rob Browning wrote:
> I happen to think
> that the changelog closes= field is the best thing suggested so far.
>
Right, and I agree.
While we are discussing the rexpr to be used, I'd ask to please consider
using:
/close[s]? \s* = \s* (?:bug)? \s* \# (\d+)/ix
without forcing use of upper
Santiago Vila Doncel wrote:
>
> Fabrizio Polacco wrote:
> > Yes, make this symlink (ln -s ../share/doc /usr/doc) on freshly
> > installed systems (where /usr/share/docs will really exist), while
> > make the opposite (ln -s ../../doc /usr/share/doc) on existing
> &
Lalo Martins wrote:
>
> Maybe we could come up with a "transition path" - like moving
> stuff like /usr/doc (less prone to make the system break) and
> then symlinking "ln -s /usr/share/doc /usr/doc"
>
Yes, make this symlink (ln -s ../share/doc /usr/doc) on freshly
installed systems (where /usr/
Martin Schulze wrote:
>
> Andreas Jellinghaus writes:
>
> > we should stop announcing and let a script on master do this.
>
> And according to James' oppionion this script should also close
> the referring bugs - opposite to closing bugs while uploading.
>
Is this script run before or after mo
For semplicity, I've moved the "conclusion" of my proposal on top of
this message. Rationale discussion follows below.
* distinguish between docs "about" a package and docs that "are" the
package.
* for "docs-about-the-package" use Schwarz's proposal:
/usr/doc//LANG__/
or /usr/doc//LAN
Civ Kevin F. Havener wrote:
>
> Dave,
>
> I can appreciate the fact that you don't like Bruce's handling of the
> project. I do like the job that Bruce is doing, however. I'll stick
> with Bruce until the normal time for succession comes, and probably
> even after that.
>
> But please, by all
Marco d'Itri wrote:
>
> [Please Cc all replies.]
> On Oct 23, Christian Schwarz <[EMAIL PROTECTED]> wrote:
>
> >I suggest to change policy so that every Debian package has to use
> >liblockdev to lock/unlock devices.
> We should not force to modify all packages, not every maintainer is
> a C pr
Quoting Kai's message you deleted the wrong parts of the message, thus
putting in Bruce's pen what I wrote.
[EMAIL PROTECTED] wrote:
> [Fabrizio wrote:]
> > > I have noticed some interesting ideas in some messages, but their
> > > language convinced me that they were not worth of my attention.
>
Kai Henningsen wrote:
>
> [EMAIL PROTECTED] (Fabrizio Polacco) wrote on 23.10.97:
>
> > Disrespectful language and obscentity disqualify only those that use
> > them. Ignoring them is the right thing to do, IMO.
>
> IMO, it depends entirely on the situation.
Ye
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 time before aba
Christian Schwarz wrote:
>
> Fabrizio, could you show us any packages where you consider the
> existance of a .tar.gz a bug?
I don't consider this existence a bug.
As I said, if I would, I'd raised bugs.
I was just wandering to hear opinions about the possibility of having
the policy say somethi
joost witteveen wrote:
> ...
> and I prefer to leave room for the maintainers.
Well, I always think that if the maintainer has a reason to do something
and assert this somewhere, he can do that way.
Then we can discuss his reasons, but this is a different thing.
> Personally, I'd say: talk to th
joost witteveen wrote:
>
> Nfsroot isn't at all for ordinary users, it's only for admins. So,
> I don't mind if ordinary (non-tar-aware) users cannot read the
> example files from nfsroot: they'll have to become "unix-aware" first
> anyway.
I understand, but maybe if we could make it "simpler" ev
joost witteveen wrote:
>
> Ah, now I see your problem.
Good.
> But usually, the right place never is /usr/doc, as usually nothing in
> /usr/doc gets used by the system (it's only there for the admin).
I thought /usr/doc is also for the admin, but mainly for the user
information.
>
> But for e
joost witteveen wrote:
>
> > I don't think that tarring files under /usr/doc/ is a good
> > thing to do.
Humm, I said tarring, not untarring.
I rephrase:
I don't think that putting tar files under /usr/doc/ is a good
thing to do.
> the problem you mentioned (dpkg not knowing what files are under
joost witteveen wrote:
>
> Then don't untar them in place!
I don't think that tarring files under /usr/doc/ is a good
thing to do.
What would be the purpose of permitting such a thing?
example files are there to be read or even browsed with your browser.
Please think that those tarballs contain
Policy 2.3.0.0 section 5.7:
>
> Any examples (configurations, source files, whatever), should be
> installed in a directory /usr/doc/package/examples. These files
> should not be referenced by any program--they're there for the
> benefit of the system administrator and users, as documentation only
Andreas Jellinghaus wrote:
>
> look at dos and windows, if you want. spliting files by type is
> superior to spliting files by package. this is unix philosophy,
> and i don't see why we should change it now. we dont need to split
> files by package, our package manager is able to handle this.
>
Christoph Lameter wrote:
>
> On Sun, 21 Sep 1997, Fabrizio Polacco wrote:
>
> >One of the things that I've heard as a distinction between RedHat and
> >debian is that we don't _permit_ others to package their software by
> >themself, as opposed to re
[moved to debian-policy, leaving debian-private]
Christoph Lameter wrote:
>
> No way. The way Andreas did it was just fine. /opt is for third party
> software and Debian is the Operating System vendor in that scheme of
> things.
>
I can summarize her the conclusion of a 1000 words message that
[this is long, very long, sorry. It also needs a comfortable chair and a
glass of Finlandia vodka near your other hand :-) ]
Proposal to split /opt from /usr
The FHS draft makes a clear separation of the fs hierarchy,
distinguishing from the four orthogonal categories of files:
+-
Andreas Jellinghaus wrote:
>
> i think it's time for a general discussion :
> where should debian place files ? /usr/local is local, so we should
> not touch it.
Right, agreed. If we all agree, I think we can drop /usr/local from our
discussion, just to keep things simpler.
> but there are sever
Christian Schwarz wrote:
>
> Now we are starting again from the beginning...
>
> I asked for this (making tetex* predepend on dpkg-perl) but Ian
> Jackson objected since this is too risky (check out debian-devel).
done.
Ian Jackson wrote:
>
> So you should not make tetex's preinst depend on dpk
tem?
Isn't it better and simple make ALL tetex* packages Pre-depends on the
package that installs the module?
Maybe I missed to include this _plainly_ in the policy proposal.
Didn't I?
Fabrizio Polacco wrote:
>
> No installation script should depend on perl modules
Christian Schwarz wrote:
>
> I still don't understand the reason (is this just me? how do the
> others think about this?). If a package installs /usr/bin/foo, why
> can't this program be used in the "postinst" script?
>
Well, probably I've skipped some part of my reasoning so, I'll try to be
mor
47 matches
Mail list logo
