On 6 Jan 2003, Colin Walters wrote:
> Since we will have to change programs anyways, we might as well fix them
> to decode filenames as well. The shell is kind of tempting as a "quick
> fix", but I don't think it will really help us.
Fixing progams that handle terminal input is a different matt
On Mon, 6 Jan 2003, Sebastian Rittau wrote:
> > I think you'd need to have all of argv be converted to utf-8 by the shell.
>
> This wouldn't work, since you're not able to handle files that are not
> in UTF-8 encoding, then. This is especially bothersome if you have some
> old non-UTF-8 files ly
On Mon, 6 Jan 2003, Richard Braakman wrote:
> I guess this conversion should be done by the user's shell, and all
> filename arguments on the command line should be encoded in UTF-8.
> Umm, except that the shell doesn't know which arguments are filenames.
> How should this be done?
I think you'd
On Sat, 29 Jun 2002, Anthony Towns wrote:
> > least implemented the same in debconf and cdebconf, it may be best if
> > packages use debconf | debconf-protocol-2.0 in their dependencies so
> > that dselect et al will pick the currently more sane choice by default.
At one point this was recommend
On Mon, 11 Feb 2002, Manoj Srivastava wrote:
> Only if the machine _has_ remained true to a known
> release. Unfortunately, a large class of machines are selectively
> upgraded. My contention is that the granularity of a Pavckage is a
There are significant number of security wary people
On Sat, 9 Feb 2002, Manoj Srivastava wrote:
> Jason> With my scheme you check the Package/Relase files that you
> Jason> kept (optional, of course) and you will detect this right
> Jason> away.
>
> How shall you detect the ssh is buggy? (We both can identify
> ssh being replaced, neith
On Fri, 8 Feb 2002, Manoj Srivastava wrote:
> >>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> Jason> If you keep the package files as you said then it all works exactly
> the
> Jason> same way as signing the individual filelists.
>
>
On Fri, 8 Feb 2002, Manoj Srivastava wrote:
> Could I keep Packages file and the Release files? Sure. Way
> more bloat. A simple signed file list is smaller, and less prone to
> error. And unless you mean to keep track of which Packages files to
> remove, man, it would get insane.
It wo
On Thu, 7 Feb 2002, Manoj Srivastava wrote:
> If you have a broken dpkg/md5sum on the machine, the only way
> to detect that after booting from known secure media (like a cdrom
> you have audited) is if the hash file were generated (and known not
> to be tampered because if a cryptograph
On Thu, 7 Feb 2002, Matthew Wilcox wrote:
> All rpm-based systems support rpm --verify. Having debsums support
> optional makes debian an inferior distribution in this aspect. Making
> DEBIAN/md5sums required rather than optional would rectify this situation.
debsums is a poor and incomplete s
On Mon, 30 Jul 2001, Manoj Srivastava wrote:
> Not quite. This only requires processing _installed_
> packages. And yes, there is a rtadeoff; Disk space for the archives,
> transfers, and CDs' vs processing when a system's integrity is under
> suspicion. The latter ought to be a rarer ev
On 21 Jun 2001, Michael Alan Dorman wrote:
> You'll probably have to run the source doc through SP or something and
> tell it to un-minimize tags first, but otherwise, a simple matter of
> style-sheet writing...
I would also be interested in such an semi-automated transform, I have
alot of text
On Wed, 9 May 2001, Anthony Towns wrote:
> On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> > I don't recall a discussion of or decision on using overrides files.
>
> Well, uh, you were in it...
>
> "Overrides files" may not be quite the most accurate way of expressing it.
> Certain
On Tue, 8 May 2001, Joey Hess wrote:
> Have you thought at all about renaming Task: to Enhances:? Dpkg already
> has some limited Enhances support, the two fields really have very close
I would prefer if Enhances remained with it's original purpose: to
maintain the idelogical purity of main but
On Tue, 8 May 2001, Marcelo E. Magallon wrote:
> seems to be missing from policy (it existed in the packaging manual).
> Is this intentional? The only similar paragraph I can find is:
APT 5 has recently begun using the highest priority (or installed) package
that satisfies the provides for ca
On Thu, 22 Feb 2001, Sean 'Shaleh' Perry wrote:
> Specifically, [!i386 m68k] seems like it could be valid, but seems to not be.
> The archs are also whitespace separated, some people are using commas.
> Perhaps
> an exmple with multiple arches would be good.
It is supported by APT..
Python 1.
On 5 Feb 2001, Brian May wrote:
> Marcelo> Jason's is actually a valid question concerning this
> Marcelo> thread.
>
> Well, sorry if I misunderstood the question, but I interpreted it as
My question was retorical. I know the answer is 'because it is too lame to
become a no-op on SUS c
On 4 Feb 2001, Brian May wrote:
> Frank> --snip -- You have to watch this one. We've found that
> Frank> things like rep require the la in the main package, not the
> Frank> dev due to linking to libltdl. This one was somewhat hard
> Frank> to discover since everyone always seems t
On Wed, 31 Jan 2001, Ian Jackson wrote:
> * You have to figure out the dependencies yourself. dpkg will stop
> you getting it wrong, but it won't tell you easily how to get it right
> and you don't get the right packages downloaded automatically. This
> is a deficiency shared by dselect and apt
On Wed, 29 Nov 2000, Reimer, Fred wrote:
> Why would they want to do this? I usually run a completely unstable system,
> that is rather stable BTW, so don't understand why someone who runs a stable
> system would want to "lie" about a package being stable when, in fact, it is
It isn't lieing, i
On Wed, 29 Nov 2000, Ben Collins wrote:
> > Mmkay... 9 Gb mirror pulse... that will work. (not)
>
> That's a seperate issue that does not pertain to the UUID's. Let's discuss
> this later.
Er, so far the only reason to have a UUID that has held up to scrutiny
revolves around whatever your si
On Wed, 29 Nov 2000, Reimer, Fred wrote:
> THEORETICALLY, if a user downloads the source and does a simple compile they
> SHOULD get the same binaries produced as the developer did. This assumes
> that they are using the standard compiler and libraries in the particular
This is a common assumpt
On Wed, 29 Nov 2000, Ben Collins wrote:
> bug/mistake in it's own right), there are potato/woody packages with the
> same version and arch, that are not the same binary. This is very
This is an archive bug and James's new scripts make it impossible.
> important from a security/signing standpoin
On Wed, 29 Nov 2000, Ben Collins wrote:
> That would be bad. Do that and then the Packages file needs regenerating,
> the package needs to be re-signed by everyone, and things will get upgraded,
> and apt[1] will redownload it all over again, just because of something
> changing like an internal
On Wed, 29 Nov 2000, Ben Collins wrote:
> > The pacakge file for woody/main would increase by at least 193k (16%
> > growth) and APT would consume 300k more ram on your average woody/potato
> > mix.
>
> In all likelyhood we could omit it from the Packages file. Also, apt need
> not keep it in it
On Wed, 29 Nov 2000, Ben Collins wrote:
> upgrading dpkg-dev, and poses little side-affects (other than a small
> increase in the size of the Packages file and .deb's in general).
The pacakge file for woody/main would increase by at least 193k (16%
growth) and APT would consume 300k more ram on
On Sun, 26 Nov 2000, Ben Collins wrote:
> > Many Progeny users files a bug on APT asking that it support clusters
> > better. I having no interest in that stuff so I drop it on a shelf for all
> > eternity.
>
> But that's very argumentative, and asks that the bug tools know the
> interests of e
On Sun, 26 Nov 2000, Ben Collins wrote:
> Then what if someone installs a Debian package on your distribution? How
> does that get handled? What if someone wants to integrate a set of
> packages from another source (not a distribution) with Debian or Progeny
> (can we say helix)?
Well clearly He
On Sun, 26 Nov 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Yes, because you ingored the discussion on -policy and implemented
> > whatever you wanted and then expected it to just become accepted.
>
> Because in my opinion that discussion di
On Sun, 26 Nov 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Yeah this isn't such a good idea. For instance I would tag some of my APT
> > builds to be
>
> Sigh. Here we go again.
Yes, because you ingored the discussion on -policy and implement
On 25 Nov 2000, Itai Zukerman wrote:
> I think the package should be able to override any default origin
> data, not the other way around.
Yeah this isn't such a good idea. For instance I would tag some of my APT
builds to be
Origin: Debian
Bugs-To: mailto:[EMAIL PROTECTED]
Which is clearly en
On Mon, 6 Nov 2000, Steve Greenland wrote:
> > Please reread my original post. Two of the three cases involve actual Debian
> > ports (either present or future).
Persumably this means some BSD thing that has been speculated about..
> 1. "Non-FHS ports". This seems to me a contradiction in terms
On Mon, 6 Nov 2000, Marcus Brinkmann wrote:
> > > 1) Non-FHS ports have problems concering the directories where things
> > >get installed (they may not match linux directories). Darwin, FreeBSD,
> > >Hurd and many others fall into this category.
> >
> > Could someone explain to me how a
On Sun, 5 Nov 2000, Ben Collins wrote:
> 1) Non-FHS ports have problems concering the directories where things
>get installed (they may not match linux directories). Darwin, FreeBSD,
>Hurd and many others fall into this category.
Could someone explain to me how a non-FHS 'Debian Port' is
On Fri, 27 Oct 2000, Anthony Towns wrote:
> I don't really see what's so "middle ground" about it; it needs much more
> significant changes to maintainer scripts [0], creates a compatability
> problem, and doesn't really seem to buy anyone anything over the simpler
> solution.
Nonsense.
>
On Fri, 27 Oct 2000, Anthony Towns wrote:
> I find it hard to believe that this thread can reasonably go from
> "there's no need for output at all for any reason" to "there's a need
> for so much output that we must be able to categorise it and filter it,
> and to hell with backwards compatabilit
On Fri, 27 Oct 2000, Anthony Towns wrote:
> > > This means future debs can't be installed with the current dpkg. It
> > > means future dpkg's can never output anything. It means all debs that do
> > > anything important in their postinst need an --assert-somethingorother
> > > in their preinst.
On Fri, 27 Oct 2000, Anthony Towns wrote:
> This means future debs can't be installed with the current dpkg. It
> means future dpkg's can never output anything. It means all debs that do
> anything important in their postinst need an --assert-somethingorother
> in their preinst. Seems like needl
On Thu, 26 Oct 2000, Joey Hess wrote:
> Jason Gunthorpe wrote:
> > The standard version would simply have to use a technique like I
> > described, you wouldn't want to be replacing programs basked on what front
> > end is being used, that is messy.
>
> Oh, you me
On Thu, 26 Oct 2000, Joey Hess wrote:
> Then dpkg-log could be replaced/coopted by these apt frontends you apeak
> of, and by debconf, so their dpkg-log versions actually handle the
> logging however they prefer to handle it. I'm not sure how things like
> apt-frontends could temporarily make the
On Tue, 24 Oct 2000, Joey Hess wrote:
> If we modify policy to say this kind of thing should be done, I'd really
> like to see it happen via some kind of mechanism that can easily let it
> be stored in a log. I know this has been discussed in the past,
> inconclusively but maybe it's time to revi
On 30 Sep 2000, Manoj Srivastava wrote:
> But only in the interim, correct? After the installation
> process is all done, the dependencies are all satisfied. During
> installation dependencies are broken, yes. Unless I am mistaken, dpkg
> tries to go from a state where the dependencies a
On 30 Sep 2000, Manoj Srivastava wrote:
> Yet another version is up at
> http://master.debian.org/%7Esrivasta/new-packaging.txt
> Ummm, could you propose corrected wording, then? Are you
> saying that pre depends and conflicts can now prevent a package being
> on the system in an
On Wed, 20 Sep 2000, Joey Hess wrote:
> I don't know about the actual code, but that's what the packaging manual
> says and I've never actually seen anyone wrap eg, a depends line (though
> I have a few I'd like to wrap..)
I have, long ago, and I think I've encouraged people to do it..
Can't
On Wed, 20 Sep 2000, Joey Hess wrote:
> > Joey> think you should point to that RFC in that section BTW, even
> > Joey> though control file format varies from it in several ways.
> >
> > Color me puzzled. If we are so different from teh RFC, why
> > should we mention it?
>
> We're not rea
On 19 Sep 2000, Manoj Srivastava wrote:
> I have put an initial draft of the new package related policy
> manual on http://master.debian.org/%7Esrivasta/new-packaging.txt. I
> have tried to trim tis down to include only stuff I think ought to be
AFIAK this is an error:
All but `Pre
On 19 Sep 2000, Manoj Srivastava wrote:
> Jason> Mark's problem *could* be addressed by making the urgencies
> Jason> sets.. First match = priority. By Mark's example you'd list
> Jason> low (< 1.2), high (< 1.4)
>
> Jason> I'd suggest the field look like:
>
> Jason> Urgency: high (< 1.2-
On Wed, 20 Sep 2000, Anthony Towns wrote:
> Another possibility (presuming you have a small number of possible urgencies),
> is to have a header more like:
>
> Most-Recent-Urgency:
> high 1.2-3
> medium 1.2-4
> low 1.2-6
Off hand this seems quite
On Mon, 18 Sep 2000, Joey Hess wrote:
> > as it is to a tool -> higher = important bug fixes.
>
> higher = important bug fixes at some unspecified point in the past.
>
> If a user sees one package with Urgency-Serial = 1109 and another with
> Urgency-Serial = 10, which will they think is more u
On Mon, 18 Sep 2000, Joey Hess wrote:
> > happened in the versions you can no longer see [1.1 to 1.3 in this
> > example]. That reduces the usability of the feature to about the level
> > of a cheap hack..
> I know. I hope someone comes up with a way to make it work. The control
> file has alwa
On Mon, 18 Sep 2000, Joey Hess wrote:
> Actually, I would prefer not to use numbers in the actual Packages file. We
> should use a textual representation; implementations can convert to
> numbers as needed. Contrast with the Priority field. Of course this
> messes with your idea of continually in
Here is a (rephrased) thought Joey Hess brought up:
Now that APT has a pinning mechanism it would be very nice if you could
automatically install higher urgency upgrades and leave low priority stuff
behind.
Right now we have an urgency feild in the changelog but that is neither
adaquate informa
On Mon, 31 Jul 2000, Wichert Akkerman wrote:
> Starting with dpkg 1.7.0 this is no longer necessary since dpkg-deb
> will reorder the files itself. The text in the packaging manual
> should be update to be something like:
The packaging manual should have text explaining what rules dpkg-deb uses
date that for QT2 if someone asks..
The basic language looks like this:
Apt is copyright 1997, 1998, 1999 Jason Gunthorpe and others.
Apt is licened under the terms of the GNU General Public License (GPL),
version 2.0 or later, as published by the Free Software Foundation. See
the file COPYING.
On Tue, 18 Jul 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > *shrug* you'll be seeing that soon enough in other forms, doesn't trouble
> > me much as long as the functionality is very tertiary.
> Can you elaborate on that? You seem to be doin
On Tue, 18 Jul 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > dpkg can access it just fine in all the contexts where a Release file
> > can exist (being called from APT basically), the only problem I see is
> > that hand installed debs would lack this
On Mon, 17 Jul 2000, Wichert Akkerman wrote:
> > > dpkg has no access to the Release file.
> >
> > Duh.
> >
> > Why don't you try to fix that instead.
>
> No, the Release file is a wrong design, dpkg *cannot* access it.
dpkg can access it just fine in all the contexts where a Release file
can
On 17 Jul 2000, Itai Zukerman wrote:
> > No, that's silly. That would mean all bugreporting tools would need
> > a comprehensive list of all Origins out there, which is not reasonable.
> Well, that's not necessarily true. The Origin field could just
> provide a *way* to get the bug-submission
On Mon, 17 Jul 2000, Chris Lawrence wrote:
> As the reportbug maintainer, let me make a few suggestions:
>
> - A debbugs BTS has more than one submission address (maintonly,
> submit, quiet). Perhaps the URL should be a pseudo-URL, like
> mailto:[EMAIL PROTECTED]
That doesn't strike me as very
On Mon, 17 Jul 2000, Jim Lynch wrote:
> > and should be merged into a single field
>
> I am not convinced of this.
Well, provide a strong reason for having two fields when they can always
be merged into one. Hint: everything else that uses RFC-822 records uses 1
field were possible, you don't s
On Mon, 17 Jul 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Consider, if Corel distributes Debian + Their Junk they will want to get
> > bug reports for the whole thing not just their packages. Having them
> > rebuild all our stuff just to chang
On Sun, 16 Jul 2000, Wichert Akkerman wrote:
> * Origin
> This lists the origin of a package. For all Debian packages this should
> be `Debian'.
This matches what is defined for the Release file..
> * Submit-Bugs-To
> An mailto URL to which bugs should be submitted. (It's a URL so
> we
unsubscribe
On Fri, 23 Jun 2000, Julian Gilbey wrote:
> All that is needed now are some patches to dinstall and apt to be able
> to handle this ;-) (I presume that the Packages.du.bz2 file would be
> generated on a weekly basis in unstable, a bit like the Contents
> files.)
Writing a contents generator sho
On Tue, 25 Apr 2000, Ian Jackson wrote:
> I think we should implement the process I sent out in a draft a week
> or two ago. No-one seemed to object very much (though perhaps people
> were just tired, and Manoj probably still objects).
I also object, I find Manoj's argument about 20 some-odd po
On Thu, 6 Apr 2000, Branden Robinson wrote:
> On Wed, Apr 05, 2000 at 02:19:28PM -0400, Thomas Bushnell, BSG wrote:
> > I think it should be a requirement that Debian maintainers have email
> > addresses which accept all validly formatted email, at least in
> > response to bug-reporting discussio
On Fri, 31 Mar 2000, Wichert Akkerman wrote:
> No, group mail is a valid group for these logfiles (it allows
> listmasters to check the logs for example).
Too many other things are group mail for that to be reasonable, like user
mail boxes for instance. Stuff that is adm is limited to log files
On Thu, 30 Mar 2000, Mark Baker wrote:
> They probably should be group adm, though.
I would like that, it is annoying to have to add all the admin people to
all sorts of groups (with unknown other repercussions) just so they can
read logs.
I think group adm should allow the reading of most, if
On 1 Feb 2000, Manoj Srivastava wrote:
> __> zgrep /usr/share/apache/icons
> /var/spool/mirror/dists/potato/Contents-i386.gz
IIRC the contents files do not have leading /'s - particularly now that my
patch to remove the ./ has been applied.
Jason
On Mon, 31 Jan 2000, Juergen A. Erhard wrote:
> If Debian should ever start restricting package inclusion based on
> what a package does (judging quality of packaging is ok), it would be
> time to fork. And I guess there'd be lots of people who'd think the
> same way.
I think if you judge 'qual
On 30 Jan 2000, Manoj Srivastava wrote:
> Why is there such an imperative need to get every peice of
> software out there i Debian, no matter how sloppily it is packaged?
I agree with Manoj, it is far more important to have a smaller amount of
really well packaged and high quality softw
On Fri, 21 Jan 2000, Ronald van Loon wrote:
> had to request an address to load your library. Things have come quite a
> ways since then. But I digress.
Welcome to ELF..
> I can only say: great. Just keep in mind that this does not work on all
> systems - but maybe that does not apply to the a
On 21 Jan 2000, Brian May wrote:
> Jason> gcc -L ./libs -lkerb5 -o libgssapi.so [...]
>
> Like I said earlier, that doesn't work if you put libtool in front of
> the command line.
If libtool doesn't do that for you but writes that info to a .la file then
it is plain and simple Broken(tm) fo
On 21 Jan 2000, Brian May wrote:
> How would you do it?
If you are using libtool and the .la has the correct information but the
.so does not have the proper depends then I think we should start
tormenting the libtool authors to fix it.
It is not hard, you just throw the right -L and -l options
On 21 Jan 2000, Brian May wrote:
> Hang on. You can't do it!!! At least, not with libtool.
What? .la files are only for static linking, we are talking about dynamic.
It is good that libtool complains :>
Look inside the .la file, it is just a text file.
Jason
On 21 Jan 2000, Brian May wrote:
> It doesn't seem to work for the Kerberos libraries. For instance,
> libcyrus-sasl needs to link in the gssapi library, from heimdal-lib.
>
> Ideally, putting -lgssapi on the command line would be good
> enough - it isn't. I get lots of symbol undefined errors.
On Thu, 20 Jan 2000, Ronald van Loon wrote:
> This is not true. Direct dependencies and the libraries needed for
> compiling are two different things. Unless the linker has become
> extremely smart, it is still necessary to specify all libraries a
No, this is wrong. With dynamic linking it is pr
On Thu, 20 Jan 2000, Roman Hodek wrote:
> However (as already said in a previous mail) I think that most shlib
> packages already do depend on other libs they need. What about
> checking for libs that have no such dependencies first?
It would be a nasty bug if this is not the case, consider doin
Hi all,
I spent the entire evening today converting VA to LDAP and cleaning out
alot of cruft. In the process I had to renumber several of CVS repository
group IDs, I hope this doesn't effect anything but if something goes
funny, this might be why.
There was some downtime on www user pages (~jgg
On 3 Jan 2000, Andreas Voegele wrote:
> I'm using vim very often after becoming super-user with su. If vim was
> linked against X, I would always get an error message on startup
> because root isn't authorized to connect to the X server.
I put
export X_AUTHORITY=/home/jgg/.Xauthority
in my .x
On 14 Dec 1999, Darren Benham wrote:
> What about all the regulations we put on shared-libs. If they're not in
> one of the key directories, do we care? Policy seems to indicate that
> there is no exemption for these beasties.
IMHO our policy guidelines for packages represent common 'good pra
On Sun, 12 Dec 1999, Anthony Towns wrote:
> On Sun, Dec 12, 1999 at 12:32:08AM -0800, Chris Waters wrote:
> > The downside is, of course, that dpkg isn't very good at ordering
> > things, but again, that's a flaw in dpkg, and I think we'd be better
> > off trying to address that, not just for es
On Thu, 9 Dec 1999, Anthony Towns wrote:
> How about coming up with something better then?
The mechanism APT uses is that Essential packages implicitly make their
dependencies also Essential for installation order - this means things
like libc6 are unpacked and configured immediately.
IHMO this
On Thu, 9 Dec 1999, Raul Miller wrote:
> Unfortunately, there are some failure modes we don't have enough
> control over.
This is the only point during dpkg's operation where a failure of dpkg is
catastrophic. IMHO essential packages should make a 'best effort' to
ensure that they have the highe
On 9 Dec 1999, Chris Waters wrote:
> I'm a little bit afraid that this opens the door to endless debates
> about what the "core functionality" of a package is. For example, I
> would have considered the "core functionality" of the bash package to
> be providing /bin/bash, but someone was trying
On Wed, 8 Dec 1999, Ben Collins wrote:
> Ok, then the only complaint I have is the part that says to remove the
> Essential status if it cannot meet the requirements of being usable when
> unconfigured. In those cases, dpkg being able to have a check for
I think this clause should be used to enf
On Fri, 3 Dec 1999, Joseph Carter wrote:
> > Why? There is nothing export-controlled about the keyring, if the keyring
> > should go anyplace, it would be data/main or just plain main.
> The keyring doesn't serve much purpose without gnupg in non-US/main.
> Since this creates a dependency of so
On Wed, 1 Dec 1999, Raul Miller wrote:
> Perhaps the keyring (entire keyring) should be in non-us rather than
> contrib?
Why? There is nothing export-controlled about the keyring, if the keyring
should go anyplace, it would be data/main or just plain main.
Jason
On 1 Dec 1999, Chris Waters wrote:
> Actually, EUDC depends on emacs. I don't think emacs should suggest
> EUDC (which is what "EUDC enhances emacs" would mean).
I think for Enhances to be (long term) usefull it should not mean the same
as suggests - Enhancing packages should not automatically
On Wed, 1 Dec 1999, Julian Gilbey wrote:
> P.S. Should the debian-keyring package now be split, with the gpg
> keyring placed in main, and the pgp keyring in contrib?
Most certainly not - GPG is perfectly capable of handling the content of
both rings. The only little problem is that some people
On 30 Nov 1999, Manoj Srivastava wrote:
> As it stands, I agree to the enhanced proposal, but would
> object strongly to using enhances to remove mention of non-free
> packages from main (we should do it in dselect, dpkg, and apt; with
> the pacjkages not displaying non-free packages u
On Tue, 23 Nov 1999, Raul Miller wrote:
> > BTW: I hope this clarification about essential will help APT not to be so
> > paranoid by not configuring every essential package just after unpacking
> > them. If APT is changed in this way, I guess upgrades will be as smooth
> > and fast as they can r
On Mon, 22 Nov 1999, Anthony Towns wrote:
> You can kind-of enforce it. ``Hey, this package does stuff in its postinst,
> get rid of the Essential tag, now.'' This is enforcable since it's already
> the case, and what we've got so far works.
I agree, essential packages by definition cannot stop
On Thu, 28 Oct 1999, Wichert Akkerman wrote:
> Let me give another good reason why using a uncompress.sh script is
> something I will never accept: it means that unpacking a package in
> an arbitrary location is no longer a guaranteed safe action, since
> uncompress.sh could do something nasty.
On Wed, 27 Oct 1999, Raul Miller wrote:
> On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote:
> > Well, if the metapackage is in the available file, the following
> > shell code will create such written list (untested):
> Last time I checked, apt-get update did not update the
On Wed, 8 Sep 1999, Marcus Brinkmann wrote:
> > Perhaps we need to add a small layer (perhaps the ctte itself) which
> > sanctions (sprinkles it with holy penguin-pee as Linus would say)
> > updates to the policy as decided by debian-policy. (perhaps sanctions
> > isn't the best word here, I hope
On Wed, 1 Sep 1999, Edward Betts wrote:
> What about multi-cd support? Apt does not have any so you have to use
> dpkg-multicd which uses dpkg -iGROEB (I think) to install from multiple CDs.
Potato APT has complete multi-cd support
Jason
On Thu, 26 Aug 1999, Roland Rosenfeld wrote:
> The solution for this problem is to use fcntl(), because Linux 2.2.*
> flushes the cache of a file in the moment when it is locked using
> fcntl().
>
> But only fcntl() locking is not enough, because Linux 2.0.* doesn't
> support this over NFS and t
On Thu, 19 Aug 1999, Anthony Towns wrote:
> > * Base-files should be changed.
>
> * Base-files must require that the fixed dpkg is installed.
>
> If base-files doesn't depend/pre-depend on dpkg, downgrading dpkg and
> downgrading any other deb that uses /usr/share/doc will lose all its
> docu
On Tue, 17 Aug 1999, Steve Willer wrote:
> >From a policy point of view, as far as I can tell, the bash failure is due
> to a dpkg bug, isn't it? I'm not completely sure if it's readline or bash
> that got removed, but my reading of the "Essential packages" section tells
It's a strange APT featu
1 - 100 of 194 matches
Mail list logo
