On Tue, 18 Aug 1998, Ian Jackson wrote:
> I. How is amalgamation of data from various sources done ?
We can probably regulate this to a more implementation issue. So long as
when the package requests something it is retrieved from -someplace-
exactly how is quite flexable.
> II. Where are the q
On Tue, 18 Aug 1998, Joey Hess wrote:
> Jason Gunthorpe wrote:
> > For simple packages I (the user) probably do NOT CARE what they configure
> > themselves to be. I have no interest in mime-type configuration, no desire
> > to do things with my mailer or apache. I just wa
We have rather a bit of a problem.. As it stands it is not possible to
locate the source tar.gz and .dsc without searching in all cases,
Consider the fragment from the package file (below). Notice how this
multi-binary package creates .debs in two sections, it is indeterminate
if the source packa
[ CC me I'm not on the list! ]
Just curious, what will APT's role in slink be? Will it be actively pushed
on the new user (ie included on the base disks) or just be another
optional utility?
It seems to me that almost all the new users of hamm are not using APT but
many of the more experianced us
On Thu, 24 Sep 1998, Enrique Zanardi wrote:
> On Wed, Sep 23, 1998 at 06:21:53PM -0600, Jason Gunthorpe wrote:
> > [ CC me I'm not on the list! ]
> >
> > Just curious, what will APT's role in slink be? Will it be actively pushed
> > on the new user (ie i
On 27 Oct 1998, Kai Henningsen wrote:
> > > My favorite is exim, because it is very configurable. Vmailer is
> > > quite limited once you try to go beyond a simple configuration.
> >
> > If anything that is the worst part of exim :| It's configuration format
> > still seems complicated to me.
>
On Mon, 30 Nov 1998, Joey Hess wrote:
> What do people here think about changing policy to reccommend that packages
> contain a md5sums file? The md5sums files have been around for over a year
> now, there is a well defined file format, tools to use it and generate it.
> The big reason to add it
On 30 Nov 1998, Ben Gertzfield wrote:
> >>>>> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
>
> Joey> What do people here think about changing policy to
> Joey> reccommend that packages contain a md5sums file? The md5sums
>
On Tue, 1 Dec 1998, Christoph Lameter wrote:
> debsums is used for md5sums generated *before* generating the .deb. They
> will detect any tampering attempts or any other accidents in the whole
> packaging in and out process. Its an attempt to guarantee that the files
> are the way they were on th
On Fri, 4 Dec 1998, Raul Miller wrote:
> One issue that's come up: we're currently doing nothing to guarantee
> that we're distributing source for three years after binaries have been
> shipped on GPLed code.
We do for things we have officially released. If you look on va there is
an archive of
On Fri, 4 Dec 1998, Raul Miller wrote:
> > > One issue that's come up: we're currently doing nothing to guarantee
> > > that we're distributing source for three years after binaries have been
> > > shipped on GPLed code.
>
> Jason Gunthorpe &l
On Fri, 4 Dec 1998, Raul Miller wrote:
> > > Really? What urls should I look at?
>
> Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> > Hmm? The archive on va is on /org/archive.debian.org/ftp
>
> If the sources are not publically accessible we're not
On 7 Jan 1999, Manoj Srivastava wrote:
> I am fairly convinced that this should be a stand alone
> program, and not built into dpkg. dpkg knows enough to function as it
> should, and we should not overload dpkg with yet another
I agree. A nice simple package with a short C program would
On Thu, 21 Jan 1999, Joel Klecker wrote:
> At 21:55 + 1999-01-21, James Troup wrote:
> >If this is really a problem which needs addresses, libc6-dev (and
> >equivalents) _must_ providing something other than libc-dev.
> >(glibc-dev maybe?) Anything else is worse than ugly.
>
> OK, proposal
[Aiie, what a huge followup list]
On Fri, 22 Jan 1999, Brian White wrote:
> Serious web hosts have probably already changed /cgi-bin/ to point to the
> correct place, thus abandoning the Debian scripts. These people will not
> be affected since we're only changing our system to match what they'
On Wed, 17 Feb 1999, Wichert Akkerman wrote:
> I really hope Ian fixes this sometime soon; I you know how dpkg stores
> all relations and packages it should not be that hard I think.
There was a long thread on the -dpkg list where I argue that this is not a
'bug' at least not something that shou
On Tue, 23 Feb 1999, Wichert Akkerman wrote:
> Previously Joseph Carter wrote:
> > gdb gives no usable output...
>
> Maybe you stripped the file? I can perfectly debug code that has been
> optimized with -O2.. (in fact I do most debugging on optimized code, I'm
> simply to lazy to remove that fl
Just as an aside,
I am hoping to get a mechanism to detect absent maintainers as we move to
having our maintainer database in a directory. My current thought is to
just turn on shadow password aging, you have to set your password once a
year or you can't upload packages, vote etc. After your acco
On Mon, 29 Mar 1999, Wichert Akkerman wrote:
> Previously Darren O. Benham wrote:
> > I *hate* expiring passwords!
>
> There is another problem: not all developers have an account on master.
> (simple example: Lars Wirzenius).
>
> Can't we do this in the LDAP database?
Eh? You can't be a Debia
On Sun, 28 Mar 1999, Darren O. Benham wrote:
> On Sun, Mar 28, 1999 at 05:21:55PM -0700, Jason Gunthorpe wrote:
> > Eh? You can't be a Debian developer without an account on master, if Lars
> Sure you can. Lars is.
Ah, let us be a little more clear here.
If we move t
reassign 34223 packaging-manual
thanks
Well, whatever you want Santiago. This is an essential APT feature, I will
not remove it just because it offends you.
Jason
On Fri, 9 Apr 1999, Santiago Vila wrote:
> reopen 34223
> severity 34223 normal
> retitle 34223 apt and packaging manual are in con
On Mon, 12 Apr 1999, Santiago Vila wrote:
> On Mon, 12 Apr 1999, Enrique Zanardi wrote:
>
> > On Sun, Apr 11, 1999 at 12:27:25AM -0600, Jason Gunthorpe wrote:
> > > reassign 34223 packaging-manual
> > > thanks
> > >
> > > Well, whatever you wa
[follow ups to -policy]
I was just taking a bit of a look around the new non-us trying to figure
out what our stance was on things like IDEA and RSA and unfortunately
can't figure it out. :| (BTW the dns has been swtiched over.. email
[EMAIL PROTECTED] if there are issues)
It seems from what I h
On Mon, 17 May 1999, Piotr Roszatycki wrote:
> For now this system seems to be useless because some Debian packages have
> md5sums file, some others doesn't.
>
> IMHO we should use this system for all packager or completly forget about it.
I agree entirely with this. Personally I think our tim
> Ok, that's a doable option, though it'll be a lot simpler to just make a
> script that traverses the archive, examines every .deb file, pulls the du
> infomation out of them and generates the master file. That doesn't require
> modifying every package and adding yet another file that must be upl
On Thu, 20 May 1999, J.H.M. Dassen wrote:
> On Tue, May 11, 1999 at 23:21:28 -0600, Jason Gunthorpe wrote:
> > However we also have libssl, openssl, cipe and ssleay in main which all
> > implement the IDEA (and RSA?) algorithms.
>
> Here's some additional information
On Wed, 26 May 1999, Daniel Quinlan wrote:
>/var/state is back at /var/lib, but using the /var/state
>specification. Moving the directory was unnecessary and was a
>stopping point for distributions. Tweaking the specification a
>little was okay, but moving it was evidently not.
On Fri, 11 Jun 1999, J.H.M. Dassen wrote:
> On Thu, Jun 10, 1999 at 23:26:32 -0500, Manoj Srivastava wrote:
> > >>"Chris" == Chris Lawrence <[EMAIL PROTECTED]> writes:
> > Chris> (gunzip upstream.orig.tar.gz; bzip2 upstream.orig.tar)
> >
> > What idf detatched signatures matter to me? O
On 11 Jun 1999, Adam Di Carlo wrote:
> Also, as discussed recently, recompressing upstream source is not
> really enough justification for dirtying the upstream source.
I like to consider the source code (.c files, etc) and it's transfer
encoding (.tar.gz) to be seperate. if you repack it, or re
On 11 Jun 1999, Chris Waters wrote:
> Jason Gunthorpe <[EMAIL PROTECTED]> writes:
>
> > - If there is no available digital signature and the work is packed in
> > an archive format that stores meta-information (OS/2 EAs, Mac
> > Resource forks, etc
On 12 Jun 1999, Adam Di Carlo wrote:
> > I like to consider the source code (.c files, etc) and it's transfer
> > encoding (.tar.gz) to be seperate. if you repack it, or recompress it, all
> > you are doing is changing the way it is delivered not what is being
> > delivered which is really what w
On 12 Jun 1999, Adam Di Carlo wrote:
> Jason, I hadn't read back on all this discussion. I caught up a bit
> more. Sorry to have you hash this out again.
Oh thats OK, with any luck it has made things clearer for everyone :>
> However, I personally would weigh in, in the case of an upstream
>
On Tue, 29 Jun 1999, Daniel Quinlan wrote:
> Did Debian adopt FHS 2.0 at any point? If it hasn't, then /var/state
> shouldn't be showing up anywhere. If Debian policy is now "FHS
> instead of FSSTND", then please nag me to release FHS 2.1 officially.
We made a statement of our intent to move t
On Mon, 19 Jul 1999, Darren O. Benham wrote:
> No reason but "ease". If you, we, the ftpmasters want to do a
> data/[main|contrib|non-free] on the same level as our current
> [main|contrib|non-free] that's ok with me. That DOES give us trees like..
Not to mention it looks like the non-us struc
On 21 Jul 1999, Philip Hands wrote:
> Gordon Matzigkeit <[EMAIL PROTECTED]> writes:
>
> > Can somebody remind me again why it's so important to be FHS-compliant
> > on this issue? Why not just change the few /usr/share/doc packages
> > back to /usr/doc,
>
> Because people who want to save dis
On Fri, 30 Jul 1999, Anthony Towns wrote:
> FWIW, I don't think forcing all packages to have postinst's and prerm's
> for the rest of eternity to be a particularly good solution either. Are
> there any fundamental problems with using a cronjob instead?
This was just discussed on irc a bit.. Ah,
On Thu, 29 Jul 1999, Joseph Carter wrote:
> /usr# mv doc share/doc/usrdoc
> /usr# ln -s /usr/share/doc/usrdoc doc
>
> dpkg would deal with that and the docs would all be under /usr/share/doc
> (though not /usr/share/doc/${PACKAGE}) which makes things still not as
> ælegant as they should be.
Ho
On Mon, 2 Aug 1999, Roman Hodek wrote:
>
> > Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your
> > friend.
>
> If it makes you lucky, think the vars re-named :-) But it really makes
> no difference, I meant exactly the same as you, i.e. ARCH == cpu.
>
> > Looks good to me. I don'
On 3 Aug 1999, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Richard Braakman) wrote on 02.08.99 in <[EMAIL
> PROTECTED]>:
>
> > Is there any case where one would want a Build-Conflicts? Allowing
> > them will complicate all the code that deals with build dependencies,
> > whether they are used
On Thu, 5 Aug 1999, Antti-Juhani Kaijanaho wrote:
> On Thu, Aug 05, 1999 at 03:40:50PM +0100, Ian Lynagh wrote:
> > What does dpkg do in the case of circular dependencies?
>
> It breaks the cycle (I'm not sure by which criteria) and configures the
> packages in the newly-defined order.
APT brea
On Sat, 7 Aug 1999, Anthony Towns wrote:
> First, this is horrible and abhorrent, and unversioned libraries shouldn't
> ever happen, and other packages shouldn't start depending on them and
> icky icky icky icky ewww.
Maybe I'm just being simple, but couldn't one simply modify the binary to
inc
On Sat, 7 Aug 1999, Anthony Towns wrote:
> The discussion in the bug report seems to have reached the conclusion
> that this can be handled simply by modifications to dinstall and apt
> (or other dselect methods as applicable): that is, to have dinstall
> generate a DiskUsage.gz file along with
On 7 Aug 1999, Manoj Srivastava wrote:
> I think you misunderstand. "without any modification to any
> existing packages, and hence policy.". As I read it, that means that
> no packages need be modified, and thus this is not policy. And such is
> the case.
That's kinda what I thought
On Sat, 7 Aug 1999, Chris Davis wrote:
> > On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote:
> > > If this is not acceptable, the amendment
> > > should be marked as rejected.
> >
> > > * If so, what syntax should we use?
> > > - My choice would be the "package (>
On Mon, 9 Aug 1999, Brad Allen wrote:
> this package have been upgraded from FSSTND 1.2 (or whatever it
> was) to FHS 2.0; please see FHS 2.0 at http://www.pathname.com/fhs/
> for details on FHS'', in case some other package developer or
> maintainer is still running a FSSTND sys
On Mon, 16 Aug 1999, Justin Wells wrote:
> responses. Here are refutations of many of the common counter-arguments:
You forgot:
"The smallest GLIBC static binary is 200k and that number seems to double
every release!"
I know the BSD's come in with about a 40k overhead for a small static
binary
> The first question is, is sash enough? It doesn't include dpkg or
> apt-get's functionality, in particular. Is that really worthwhile
> though? What sort of failure modes are there that a statically
> linked dpkg/apt would help with that are actually plausible. I
> assume min
On Tue, 17 Aug 1999, Ian Jackson wrote:
> I'm not sure yet what the test cases people are presenting are. dpkg
> is not supposed ever to remove a nonempty directory and replace it
> with a symlink to a different directory. If someone can reproduce it
> doing this I'd be very interested.
One (t
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
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 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 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 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, 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 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 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 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 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 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 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, 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 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, 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 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 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 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 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 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 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
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 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
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 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 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:
> 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:
> 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 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 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 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 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 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 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, 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 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 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
unsubscribe
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
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 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, 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 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, 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 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 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
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 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
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, 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
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:
> > 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
1 - 100 of 194 matches
Mail list logo
