Bug#768117: debian-policy: WSGI API must distinguish between Python 2 and 3
On 24 November 2014 at 05:08, Bill Allombert wrote: > Thanks for your clarification. Is the attached patch OK ? That looks good to me. -- Brian May
Bug#768117: debian-policy: WSGI API must distinguish between Python 2 and 3
Package: debian-policy Severity: normal The httpd-wsgi virtual name was added in response to #588497. However, as per the following email: https://lists.debian.org/debian-devel/2014/09/msg00719.html "WSGI is an API, not a wire protocol. The Python version of the WSGI server would also be the Python version the code is run under, so we must distinguish between Python 2 and 3. The best way would probably be to specify that httpd-wsgi is for Python 2 and create a httpd-wsgi3 virtual package for Python 3." This means, as currently written, Python2 packages that depend on httpd-wsgi might get a Python3 implementation of WSGI, which won't work. Similarly, Python3 packages that depend on httpd-wsgi might get a Python2 implementation of WSGI which also won't work. We need two virtual package names, one for Python2 and one for Python3. I raised this issue on debian-devel, but unfortunately got noreponse, so am raising it here. Thanks -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105033839.12635.56418.report...@aquitard.in.vpac.org
Re: BDF Considered Harmful?
Stefano Zacchiroli wrote: > This is not the right analogy. A C source file by itself cannot be run > without having been compiled while, AFAICT from the given description, > a BDF "source" file can be. Make an analogy with Perl source file, it > will work better: they do have copyright notices and comments, yet we > ship them in binary packages. > With Perl you have no choice. AFAIK there is no binary Perl format. > A question I have and that hasn't been addressed by the original > request is: what is the advantage to have BDF files in binary > packages? Comments and copyright notices don't look like a real > advantage to me. > Copyright notices belong in /usr/share/doc/package/copyright. -- Brian May -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Putting .so symlinks in libs package for dlopen()ing?
On Mon, Dec 09, 2002 at 11:26:14AM +1100, Timshel Knoll wrote: > 1. Put the .so symlinks in the libreiserfs-0.3-0 package. This breaks >policy (section 9.0 says that the associated development package >should contain the shared library without a version number). This is >also a really bad precedent to set for other shared library packages >which are dlopen()d. Just for the record, this is bad not just because policy days it is bad ;-), but it prevents installing multiple versions of the library at the same time. -- Brian May <[EMAIL PROTECTED]>
Re: Question about build dependencies.
>>>>> "Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: Marcus> On Mon, Dec 17, 2001 at 05:19:07PM -0500, Joey Hess wrote: >> Anyway, one can put a cvs checkout in the build rule w/o >> breaking any autobuilders, if you're really >> careful. base-config has had this for ages, without causing any >> problems: Marcus> Sure. But it does open a security risk. If people manage Marcus> to trick the builder into downloading files from their Marcus> server instead the real one, and use them for building the Marcus> package, this can lead to serious problems. Another problem is that there is no guarantee that the same source code will be used for every architecture, depending on the timing the autobuild has taken place. This, I believe, is probably the most likely and most serious problem, there is only one tar.gz file for all architectures... Perhaps the autobuilders should (if they don't do so already) check that nothing in the source code has changed from the downloaded *.dsc, *.tar.gz and *.diff.gz files? (might be a problem for autobuilt rebuilt files, eg. autoconf and automake, though) -- Brian May <[EMAIL PROTECTED]>
Re: Should debian policy require to use debconf for postinst scripts?
>>>>> "Anthony" == Anthony Towns writes: Anthony> Consider, eg, #90676. What is the problem here? If a program tries to read an input from STDIN, then IMHO it is not debconf compliant, as you will still have problems with automatic installations. This is just one bug I have seen with packages that use debconf. Another one is packages that insist on asking the questions twice: once after apt has downloaded the package and once for after the package has been unpacked. Sometime I probably should test some suspect packages for this problem and file bug reports. -- Brian May <[EMAIL PROTECTED]>
Bug#117916: debian-policy: New virtual package httpd-cgi.
>>>>> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes: Chris> This part of policy is not very clear. As I read it, you Chris> don't need to make a formal proposal for new virtual Chris> package names (or menu categories); you just have to Chris> discuss the proposal on d-policy. If nobody complains, Chris> you're in. This is, I believe, the reason that the virtual Chris> package list (and the menu tree) are kept as separate Chris> documents: so that they can be updated separately. >From zless /usr/doc/debian-policy/virtual-package-names-list.txt.gz: [...] Packages MUST NOT use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in this list. [...] The procedure for updating the list is as follows: [...] 3. Mail the maintainer of the virtual package name list (which is the Debian Policy list ) notifying them of the consensus reached (or your suggestions if noone objected). Please update the bug report at the same time (retitling the bug to [ACCEPTED] Please include a proposed brief description of the new virtual name(s) for the list. The list maintainer will then post the new list to debian-devel and upload it to the FTP site. 4. Go and use the new or changed names. [...] I thought this was clear enough myself (however I did truncate steps 1 and 2 so read the document yourself). Chris> As for the proposal itself, "http-cgi" seems like a Chris> reasonable name, and a reasonable virtual package. The Chris> only thing I'd ask is this be added to the daemons *before* Chris> any packages try to use it as a dependency. Get in touch Chris> with the httpd maintainers, and make sure they're ready and Chris> willing to do this, and (if no one has objected by that Chris> time) we should be go. -- Brian May <[EMAIL PROTECTED]>
Bug#109171: Use Maildir format by default
>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> Use quoted-printable. Ok, I didn't realize that quoted printable coped with this. My experimentation shows that a line starting with From is turned into "=46rom" (using mutt). Not very readable to a human reader, but at least any program that understands quoted-printable (including mutt) can display it properly. This was GnuPG signed, with OpenPGP non-compliant options removed, and the signature came out looking OK. -- Brian May <[EMAIL PROTECTED]>
Bug#109171: Use Maildir format by default
>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> [I know this thread is old.] Raul> On Sun, Aug 19, 2001 at 08:31:58AM -0700, Aaron Lehmann wrote: >> I'm interested in performance differences. A big flaw of the >> mbox format is that every byte of the file must be read to >> extract headers of the messages .. i.e. display a list of the >> messages without necessarily showing any data. Does maildir >> employ a summarization technique or must an MUA open every >> single file to extract the mailbox headers? Raul> No. Raul> Also note that mbox format need not be lossy -- MDA should Raul> quote with > any line matching regexp "^>*From ", MUA should Raul> always remove one level of quoting at display time. Any Raul> software not following this is losing information (and Raul> therefore buggy). What is suppose to happen to signed messages? Current practise, I believe is to quote the "From" headers before the message is signed, in which case the quoting cannot be removed without damaging the signature. >From my ~/.gnupg/options file: # Because some mailers change lines starting with "From " to ">From " # it is good to handle such lines in a special way when creating # cleartext signatures; all other PGP versions it this way too. # To enable full OpenPGP compliance you have to remove this option. escape-from-lines which is really stupid IMHO, as it means the message gets converted for mbox format before it is even sent. -- Brian May <[EMAIL PROTECTED]>
Re: debconf dilemma
On Mon, Sep 03, 2001 at 09:56:31PM -0500, Scott M. Dier wrote: > But, neither was debconf purpoused to becoming documentation for users > during configuration. Telling users to reference something like > README.Debian works in all situations except for those in the very > earliest stages of system installation. It is a problem whenever you install a package using apt, as apt (if configured) will always use preconfiguring, regardless of what information is/isn't in README.Debian. Also when installing packages with apt, my aim is to get everything configured as quickly as possible, so that vital services aren't shutdown. I don't want to get into the situation that I can't configure a vital package, because apt wants to configure a complicated package first, but I don't know how to answer a difficult question, because I need to learn how to use the package first, which requires reading the documentation first, which has not even been installed yet. -- Brian May <[EMAIL PROTECTED]>
Re: debconf dilemma
>>>>> "Scott" == Scott Dier <[EMAIL PROTECTED]> writes: Scott> Elements A possibly common user error could be Scott> helped by inserting information into a debconf information Scott> dialog before a long list of choices or it could be I have not yet read the rest of the replies, but this is one practise I object to. For instance, when configuring xserver-xfree86, I see an information screen on the different types on keyboards that are supported. Fine. Next page please. At this point, I am confronted with a dialog asking me what type of keyboard I have. Damn... should have read that last screen in more detail. Only now, with my selected debconf front end (dialog), it is too late. Nor can I go back to view the information screen again. So, I have to guess at one of the types, and remember to redo the entire X configuration again after apt finishes installing everything else. While I have no problems with this as an experienced user, for a novice it could makes things rather confusing. It seems however, that in the latest version of xserver-xfree86 this question has been removed? However, exactly the same problem exists for selecting colour depth. As far as I can tell, this problem is with the debconf front end, not with xserver-xfree86. Scott> included in documentation. However, another possibly Scott> common issue is allready included in that packages debconf Scott> template. Scott> The maintainer has also been asked not to add more Scott> "chatter" into the debconf interaction, while others ask Scott> for more information to beable to make decisions on Scott> questions such as the above. I think this is an issue for debconf and/or front end user interfaces for debconf. I think it should be possible for the user interface to display *all* information relating to a question, *if* the user needs it, eg. with a "help" button. This is probably already possible to, just as long as the maintainer has included the information in the correct spot. So relating to the above case, I do not need any detailed description for most settings like "default depth?" and "is monitor LCD?", but may need more help *after* I see the keyboard layout question in order to answer it. AFAIK the only problems with this currently are: 1. some front ends display the information at the wrong time, and require manually pressing enter to acknowledge, so you see the verbose information (which may not even be important) before you get asked the question. 2. some front ends, eg. text will always display the verbose information even if it is not required, hence forcing other messages to scroll of the top of the screen. 3. some questions are poorly described. eg. for configuring mouse, in the slang front end, I see a pull down list of mouse types and the following description: "If in doubt choose the first option". Just what is the first option? Can you even rely on the front end not to reorder the list? Both issues 1 and 2 are non-existant in front ends like the slang front end. (although I have never been quite sure - how do you scroll down the help window if it is too big? Also might be good if you could expand the help window to fill the entire screen). Scott> One Possible Solution - Remove most Scott> informational displays from debconf that aren't relating to Scott> critical or grave issues. Put other information in either Scott> the README.Debian or other documentation, such as the Scott> release notes. Strongly disagree for a number of reasons. Remember, that README.Debian isn't available for pre-configuration. -- Brian May <[EMAIL PROTECTED]>
Bug#108416: Format of short description should be mandated
>>>>> "Branden" == Branden Robinson <[EMAIL PROTECTED]> writes: Branden> gcc - The GNU C compiler. gcc-2.95 - The GNU C compiler. Branden> gcc-3.0 - The GNU C compiler. gcc272 - The GNU C Branden> compiler. Branden> IMO, there is room here for just a little bit of Branden> clarification. Is it really required to duplicate the information already present under the Version and Package field in the description field? Perhaps a better approach, if the descriptions must be different, would be to add something like (obsolete version), (current version), (newly released version), (beta version), (alpha version), or (dangerous version) instead. -- Brian May <[EMAIL PROTECTED]>
Re: packages without .md5sums file?
>>>>> "Adam" == Adam Heath <[EMAIL PROTECTED]> writes: Adam> On Sat, 28 Jul 2001, Marcus Brinkmann wrote: >> In contrast, if the md5sums are stored in the package on CD, >> verification is easy: You just need to boot from the (trusted) >> CD, and kick off the comparison with the CD content. It is >> easier to trust a list of checksums mirrored world wide and >> verified by many users than to trust a list which is generated >> by the system you want to verify. Adam> Boot from said trusted CD, run said trusted dpkg, to Adam> calculate the md5sums of the files. Which requires scanning each and every *.deb file, in order to calculate the expected checksums of each individual file. What is the performance lost here? -- Brian May <[EMAIL PROTECTED]>
Bug#106280: packages shouldn't have to ask permission before calling MAKEDEV in postinst
>>>>> "Anthony" == Anthony Towns writes: Anthony> On Mon, Jul 23, 2001 at 02:01:02PM +0200, Paul Slootman Anthony> wrote: >> I suggest the last line be changed to something like: after >> notifying the user. This notification could be done via a >> (low-priority) debconf message. Anthony> ...or an "echo". Seconded. Only one concern: such a message should *never* get displayed if you are using devfs... -- Brian May <[EMAIL PROTECTED]>
Re: [russell@coker.com.au: Re: Adding device file to /dev.]
>>>>> "Arthur" == Arthur Korn <[EMAIL PROTECTED]> writes: Arthur> MAKEDEV does check for /dev/.devfsd, so as long as people Arthur> use MAKEDEV they don't have to bother. but packages still will print messages when creating devices. Packages should either: a) not print any messages when creating devices or b) only print messages if ! devfs. Otherwise, seeing messages that devices are being created on a devfs system can only cause confusion. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#99324: Default charset should be UTF-8
>>>>> "Radovan" == Radovan Garabik <[EMAIL PROTECTED]> writes: Radovan> CJK and similar require much different characters fonts then VGA Radovan> hardware is capable of displaying in text mode - so they neither Radovan> can be supported, unicode or not. Does framebuffer solve this? -- Brian May <[EMAIL PROTECTED]>
Re: mandate ldconfig -X?
>>>>> "Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: Marcus> We could make it bail out with an error if something is Marcus> requested which isn't implemented. Sometimes, Marcus> debian/rules scripts run ldconfig to set links. So we Marcus> want to provide an ldconfig dummy script which will error Marcus> out for any unsupported operation, and only return success Marcus> silently for operations which are unnecessary on the Hurd Marcus> (as rebuilding the cache). Are you saying ldconfig can't update the links on Hurd? Can this be fixed? My only concern is that the solution to another policy proposal presented to debian-policy (assuming it still exists) involves moving the symlinks outside of the package, and creating dynamic links with ldconfig instead. This would allow installing multiple libraries at the same time, if the major number is the same, but the minor number is different. (please send followups to the most appropriate policy bug report). -- Brian May <[EMAIL PROTECTED]>
Re: mandate ldconfig -X?
>>>>> "Robbe" == Robert Bihlmeyer <[EMAIL PROTECTED]> writes: Robbe> For one, it is unnecessary, and wastes time. But more Robbe> importantly, the Hurd has no ld.so.cache, which kills Robbe> reason 2 on this platform. Debian GNU/Hurd systems also Robbe> don't have reason 1, so there is currently no real ldconfig Robbe> program on the Hurd. Rather than writing a program that's Robbe> completely pointless, I'd rather we called ldconfig Robbe> correcly, i.e. with the -X parameter. "ldconfig -X" will Robbe> just do nothing on the Hurd. I fail to see: What is wrong with the current practise on the Hurd, where ldconfig is a do nothing program? How does disabling task 1 (creating the links) help for the Hurd? -- Brian May <[EMAIL PROTECTED]>
Bug#99324: Default charset should be UTF-8
>>>>> "Cesar" == Cesar Eduardo Barros <[EMAIL PROTECTED]> writes: Cesar> - Making sure everything works with UTF-8 charset Biggest problem for me, here (unless that has changed in the past month or so) is xemacs. Probably the same for emacs too, not sure. Once I opened a message, and Gnus had heart failure when it said it couldn't find the UTF-8 charset inside xemacs (actually, the message was ISO-8859-1, so it doesn't entirely make sense), (I don't have a UTF-8 font installed, but I haven't looked hard, yet; there are probably plenty of choices already packaged for Debian; however, I doubt that is the reason for xemacs not supporting it). Cesar> - Adding UTF-8 charset for every locale Cesar> - Converting (in debian/rules) documentation files to UTF-8 Cesar> - Selecting en_US.UTF-8 (or something like that) as the default for LANG= Cesar> - Echoing some magic sequence on every getty to convert the kernel mode to UTF8 These sound like time consuming tasks, so the sooner we start, the better. Just don't expect to finish for a while (eg. aim for woody+1). First priority should be to ensure that all programs work with UTF-8. Ideally, this should be done for woody (but may not be possible). How do tools (eg. debconf) know what coding set to use when reading a file (eg. templates file)? Or, is ISO-8859-1 assumed? -- Brian May <[EMAIL PROTECTED]>
Re: 7.5.1 Overwriting files in other packages
>>>>> "Seth" == Seth Arnold <[EMAIL PROTECTED]> writes: Seth> And, as far as I can tell, yes, it is always true that Seth> usually it is an error for two packages to contain duplicate Seth> files when both can be installed on a system. Except for when the package uses the "Replaces: " header... -- Brian May <[EMAIL PROTECTED]>
Re: arch: lines, for not-just-linux debian. (was Re: Hurd and architecture)
>>>>> "Brian" == Brian Russo <[EMAIL PROTECTED]> writes: Brian> hm, both have problems Brian> hurd-i386, linux-i386 has the problem of.. really long Brian> arch: lines Brian> Arch: linux-i386, linux-ppc, linux-m68k, linux-alpha, Brian> linux-sparc, hurd-i386, hurd-ppc, hurd-m68k, hurd-alpha, Brian> hurd-sparc ... etc Brian> OTOH Brian> Kernel: linux, hurd Arch: i386, ppc, m68k, alpha, sparc Brian> is easier on the eyes, but I'm not sure what you do if you Brian> want to say linux (i386, ppc, m68k, alpha) and hurd (i386, Brian> ppc, m68k) - but not hurd(alpha) This is a topic that we have been discussing on and off in the debian-hurd mailing list. Please see the archives, especially for earlier this year. -- Brian May <[EMAIL PROTECTED]>
Bug#90511: proposal] disallow multi-distribution uploads
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> upload to stable == upload to stable Brian> + source only upload to testing Brian> + source only upload to unstable Sorry to followup straight away on my previous post, however I just thought of something. What problem would it cause if source only uploads to "stable unstable" where allowed? (don't say the auto-builders would get confused, because if that is the only reason then it should get fixed). As I mentioned in my previous mail, testing may raise issues that need to be solved. -- Brian May <[EMAIL PROTECTED]>
Bug#90511: proposal] disallow multi-distribution uploads
>>>>> "Anthony" == Anthony Towns writes: Anthony> So, rather than uploading to "stable unstable", you Anthony> upload just to "stable", and the change automatically Anthony> gets propogated to unstable (and/or testing), unless Anthony> there's a newer version already there. This sounds like a good idea. Except only the source code can be transfered from stable to unstable (to prevent problems others are debating), which will mean: upload to stable == upload to stable + source only upload to unstable So one way or the other source only uploads need to be fixed. I haven't considered testing in the above, the actual equation might look more like: upload to stable == upload to stable + source only upload to testing + source only upload to unstable ...but I am not sure of auto-builders using testing, or if any are even available. Building against unstable and putting the result straight into testing could be bad, if libraries don't exist in testing for instance. I guess this is an issue that needs further discussion. I guess the upload to unstable should be omitted if this is an earlier version. Same with testing. You could also argue that the initial upload should be source only to. That way you wont encounter bugs dues to maintainers accidently building using unstable libraries. -- Brian May <[EMAIL PROTECTED]>
Bug#90511: proposal] disallow multi-distribution uploads
>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: >> This is a different issue. Besides, you won't solve it by >> gettint people to do different uploads since they can compile >> both on stable (some developers only run stable machines >> immediately after a release). What you need to here is to file >> bug reports against packages that compile against obsolete >> sonames. I realize this is getting off-topic for the thread, but if it ever becomes a problem that packages in unstable should be compiled against unstable, I would suggest fixing source only uploads first (that way maintainers don't have to run unstable). -- Brian May <[EMAIL PROTECTED]>
Bug#90287: PROPOSAL] require the use of $MAIL
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: >>> The mail spool is $MAIL with a fallback to >>> /var/spool/mail. The interface to send a mail message is >>> /usr/sbin/sendmail (as per the FHS). The mail spool is part of >>> the base system and not part of the MTA package. I think the proposal was for the MUA, not the MTA (which would have to be configured separately). -- Brian May <[EMAIL PROTECTED]>
Re: Package documentation
>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> If the maintainer can't add "The docs reference paths that do Ben> not exist on a Debian system" to README.Debian, then I would Ben> think something is severely wrong with how the package is Ben> maintained. I would suggest that it would be better use of the maintainers time fixing problems. Maybe not immediately, but whenever convenient. Also, I would encourage the upstream maintainer to create the documentation (eg. man pages) dynamically (eg. pre-processed by sed, m4, or whatever), so the paths will always be correctly set (especially for packages based on autoconf). -- Brian May <[EMAIL PROTECTED]>
Bug#88058: PROPOSAL] ftp-client virtual package
>>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: Julian> The ftp and ftp-ssl packages have started providing the Julian> ftp-client virtual package. The ncftp package may well do Julian> so as well soon. This package should therefore be Julian> included in the virtual packages list. Can any ftp client provide "ftp-client"? What about X clients? Or, put another way, what packages, if any, would Depend/Recommend/Suggest/Conflict with ftp-client, and why? I guess packages you should look at include: webcam, task-dialup(?), dftp, urlview(?), devscripts, quinn-diff(?) (quick glance through my Packages file at packages that depend/suggest/recommend ftp, ncftp, or lftp). This is the problem I faced when I considered making it a virtual package previously. I am not sure that a package which depends on ftp would work with ncftp, for instance. Somebody suggested to use ftp-client-traditional (or was that traditional-ftp-client?) instead. -- Brian May <[EMAIL PROTECTED]>
Bug#88029: allow rules file to be non-makefile
>>>>> "Josip" == Josip Rodin <[EMAIL PROTECTED]> writes: Josip> Imagine a rules file like this: that seems to have limited functionality compared with the makefiles I have seen. for instance debian/rules binary will not invoke the "build" target automatically. The makefiles I have seen will automatically execute the build target if the stamp file has not been created. (is this required by policy?) -- Brian May <[EMAIL PROTECTED]>
Re: Bug#88029: allow rules file to be non-makefile
>>>>> "Alexander" == Alexander Hvostov <[EMAIL PROTECTED]> writes: Alexander> My point: Using interpreted languages in rules files Alexander> should be avoided. Otherwise thou canst not build eg Alexander> python without already having python installed... and Alexander> you get a chicken-and-egg problem. Ouch. You don't consider make to be an interpreted language? -- Brian May <[EMAIL PROTECTED]>
Re: seeking resolution to issues I have raised
>>>>> "Gordon" == Gordon Sadler <[EMAIL PROTECTED]> writes: Gordon> Clarification here. Since libtool is Priority: Gordon> optional... shouldn't packages that use it Build-depend on Gordon> it? If so you can use that to determine libtool was used, Gordon> therefore .la files should be shipped as well? No. Packages generally come supplied with a copy of libtool. Build-Depends: libtool is only required if the package executes libtoolize somewhere in the build scripts. However, you should be able to tell by looking for the files "config.guess", "config.sub" and "ltmain.sh". (some earlier versions also have "ltconfig"). -- Brian May <[EMAIL PROTECTED]>
Re: Frozen distribution?
>>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: Julian> Why suddenly change the model like this? Would the Julian> following not be better and perhaps less confusing, still Julian> using a four-tier setup: I tend to agree. Basically the proposal is to map: unstable --> experimental frozen --> unstable frozen+10 days --> testing stable --> stable why not keep unstable as unstable, and just insert a new frozen: unstable --> unstable (never goes into frozen) frozen --> frozen frozen+10 days --> testing stable --> stable that way "frozen" is treated in exactly the same way testing use to be, but uploads are restricted, and instead of forcing unstable updates to be uploaded to experimental (hence changing the meaning of experimental), they are simply uploaded to unstable. (consider the time required to move packages from experimental to unstable after the freeze - I suspect that would have to be significant, too). Same stages as proposed, just different names. -- Brian May <[EMAIL PROTECTED]>
Re: Frozen distribution?
>>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: Julian> On Fri, Feb 16, 2001 at 02:04:24PM +1100, Brian May wrote: >> What is the benefit of this new frozen stage, instead of just >> freezing the testing stage? Julian> That people who want to be almost bleeding edge will be Julian> held back for three months of freeze. Why? You can just use unstable like you currently do. There is no reason why unstable should change just for the freeze. -- Brian May <[EMAIL PROTECTED]>
Re: Frozen distribution?
>>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: >> 1. Create frozen between testing and unstable, initially as a >> copy of testing. 2. Create frozen between testing and >> unstable, initially as a copy of unstable. Julian> Surely 2 defeats the whole purpose of testing? My I think it depends on the policy used to move frozen --> testing. For 1, you could use (for instance): unstable --> frozen: must be done manually frozen --> testing: using same procedure as currently used for unstable-->testing? For 2, unstable --> frozen: ? frozen --> testing: must be done manually Julian> question was: will there be a frozen or not during the Julian> freeze: Julian> Possibility 1: We freeze testing and allow it to Julian> stabilise, allowing upgraded packages into testing only if Julian> they are deemed necessary by the release manager, then we Julian> release testing as the new stable. Finally, after the Julian> release, we start allowing the unstable -> testing flow Julian> again. Julian> Possibility 2: Your possibility 1, so that there are four Julian> distributions during the freeze; testing continues to Julian> carefully follow unstable, and frozen is, well ... frozen. What is the benefit of this new frozen stage, instead of just freezing the testing stage? -- Brian May <[EMAIL PROTECTED]>
Bug#85270: PROPOSAL] Forbiding debian-revision field for Debian-native source packages
>>>>> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Previously Brian May wrote:
>> ...and why is an empty diff file, for a small (if not tiny)
>> number of packages such a problem?
Wichert> It's impractical. The way I use version numbers is that I
Wichert> increase the version number if I change the source, and
Wichert> only increase the revision if I only change debian/. That
Wichert> doesn't make it any less Debian-native, but makes it
Wichert> obvious what kind of changes I made in the package.
Thats the very situation though that people have said they dislike.
It means if you make a minor change to the debian/ directory, you
have to upload a new copy of the entire source code.
If you just made it a native package, these changes could be
represented in diff form without having to down-load the entire
source.
Seeing you already use the debian revision number, why not take
it to its full potential?
(that way you also get the added benefit that the original tar.gz file
is "pristine source" compared with what you distribute elsewhere)
--
Brian May <[EMAIL PROTECTED]>
Bug#85270: PROPOSAL] Forbiding debian-revision field for Debian-native source packages
>>>>> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes: Henrique> Does Katie detect when a native upload is done instead Henrique> of a non-native upload, even when the upstream version Henrique> is increased? If she does, we indeed have no need for No. Just recently, I uploaded a native version of Heimdal (0.3d-5), when the previous version was non-native (0.3d-4). Note: same upstream version. No problems. When I wanted to fix the problem, I uploaded Heimdal 0.3d-7 with upstream source again (same copy), and never had any problems. -- Brian May <[EMAIL PROTECTED]>
Bug#85270: PROPOSAL] Forbiding debian-revision field for Debian-native source packages
>>>>> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes: Wichert> FWIW, if this change gets accepted all my currently Wichert> Debian native package will suddenly no longer become Wichert> Debian native and get an empty diff file. ...and why is an empty diff file, for a small (if not tiny) number of packages such a problem? My only concern with the policy change, is what defines a "native package"? I would say, something along the lines of: it is up to the maintainer to decide if a native package is used or not, but packages generally should not[1] be native if upstream author != maintainer. (do we need to include anything on uploading a native package if the last one was non-native and vice versa? eg. only allow it if the version number (excluding debian revision) changes?) Note: [1] must not? -- Brian May <[EMAIL PROTECTED]>
Re: suid binaries should not be writable by owner
>>>>> "Massimo" == Massimo Dal Zotto <[EMAIL PROTECTED]> writes: Massimo> chattr +i ? Interesting point. Programs/packages shouldn't rely on it working all the time though, as I doubt it is (yet) supported on NFS, resierfs, Hurd, etc. -- Brian May <[EMAIL PROTECTED]>
Re: suid binaries should not be writable by owner
>>>>> "s" == s Lichtmaier writes: s> It's tricky... capabilities don't fix this. I was considering the case where setuid root may not be required because capabilities could be used instead. s> And I know nothing about ACL's on UNIX systems. It must be s> something like "these users/groups may write, and these may s> read", but I don't know if they have something for the s> setuid/segid thing... Yes. I was wondering the same thing myself... -- Brian May <[EMAIL PROTECTED]>
Re: suid binaries should not be writable by owner
>>>>> "s" == s Lichtmaier writes: s> A better design would have been having the file to have a s> second UID/GID. s> So, a file could be owned by root, but setuid man. ACLs and capabilities are probably two very different solutions to this problem. (...depends on how they are implemented). -- Brian May <[EMAIL PROTECTED]>
Re: suid binaries should not be writable by owner
>>>>> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> Argh, egg on face: linux lets the owner of a file modify it Joey> even if it is mode 444 and in a directory they do not Joey> own. Yuck! Is this standard unix semantics? It sucks. The directory is irrelevant - you are not changing the directory, only a file (technically the inode) within. However, I am a bit surprised you can edit the file, normally you would have to make it 644 first. Perhaps your editor or whatever does this for you? As an example: [578] [snoopy:bam] /tmp/a >ls -l total 0 -r--r--r--1 bam root0 Feb 6 14:30 b [579] [snoopy:bam] /tmp/a >echo aaa >> b zsh: permission denied: b [580] [snoopy:bam] /tmp/a >chmod 644 b [581] [snoopy:bam] /tmp/a >echo aaa >> b Where a has: drwxr-xr-x2 root root 4096 Feb 6 14:30 ./ This is standard Unix semantics. Sooo... your proposal might get a little gain in security, but not much, since the owner of the file can just turn on write permission anyway. -- Brian May <[EMAIL PROTECTED]>
Re: native pkg versioning (was Re: Question about native packages)
>>>>> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> On the other hand, it's a sign of laziness, and I think
Chris> laziness is a virtue, so I have mixed feelings about the
Chris> whole thing. In general, laziness can be a great boon if
Chris> applied intelligently ("I'm tired of adding up columns and
Chris> rows of numbers all the time, I think I'll invent the
Chris> spreadsheet so the computer can do this for me.") I think
Chris> the best thing is to continue to allow this, and only
Chris> complain in cases where the package is so large, and
Chris> uploaded so frequently, that it really is a problem for our
Chris> mirrors.
I disagree. Why should dpkg, for instance, which is specific to Debian
come with a diff format.
So maybe native format might be used when it shouldn't, but that
doesn't mean that some applications exist. IMHO all packages that are
specific to Debian (eg. use on other platforms is not supported) fall
into this category.
--
Brian May <[EMAIL PROTECTED]>
Bug#83669: dynamic creation of libx.so.n
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> On Mon, Feb 05, 2001 at 01:13:44PM +1100, Brian May Herbert> wrote: >> As such, I recommend that we change this bug title to: >> >> "dynamic creation of libx.so.n" Herbert> Sorry, but this has been solved ages ago in ldconfig :) Maybe so, but then Debian packages shouldn't include the symlink in the runtime library package. Also, who is responsible for deleting the symlink when it is no longer required? Does ldconfig do that? -- Brian May <[EMAIL PROTECTED]>
Bug#83669: dynamic creation of libx.so.n
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> For everyone concerned: versions of libtool already support Brian> this. eg. cvs version of libtool 1.4, and cvs tree for Brian> libtool 1.3x (not sure if includes the latest release of Brian> libtool or not, it definitely includes the libtool CVS Brian> version under projects/experimental, as Heimdal already Brian> uses the new system). As such, I recommend that we change this bug title to: "dynamic creation of libx.so.n" As this is the next issue at hand. In order to utilise the benefits, it should be possible to install multiple versions of the library at the same time, which means that the above symlink has to be created dynamically. update-alternatives might be a good approach to use here. -- Brian May <[EMAIL PROTECTED]>
Re: Please add auto-forwarding feature to BTS (was: Directing Debian users to use project BTSes - should we?
>>>>> "Jim" == Jim Lynch <[EMAIL PROTECTED]> writes: Jim> Hi, Automatically forward bugs upstream? OK, if each upstream Jim> agrees they want ALL the bugs reported. (already evident in Jim> current threads to the contrary, however; maintainers know Jim> who their upstream is, and can forward. There is mechanism Jim> to flag a bug as having been forwarded upstream. So: what, Jim> exactly, is missing??) My only concern with this proposal is as follows: what happens if both maintainer and upstream try to fix the same bug? Wasted effort. However, if maintainers are happy to accept this risk, I have no problem with it. -- Brian May <[EMAIL PROTECTED]>
Re: native pkg versioning (was Re: Question about native packages)
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> Say, I have a native package foo. Now, foo is small, Manoj> and for the most cases the changes I upload reflect changes Manoj> in the source; and in the case there is only a packaging Manoj> change, well, the debian diff is the same order as the Manoj> whole package, so it does not make any sense to create a Manoj> separate debian revision. In case you want a diff file, then just treat the whole package as a normal non-native package. No problem. Manoj> I want to have foo_1.1.dsc foo_1.1.tar.gz foo_1.1_i386.deb Manoj> bar_1.1.orig.tar.gz bar_1.1-13.dsc bar_1.1-13.diff.gz Manoj> bar_1.1-13_i386.deb Exactly the same as a non-native package. No one (as far as I am aware) is trying to force you to create a native package just because you happen to be the author as well as the packager. You have to be careful to keep the roles (upstream author vs maintainer) separate (eg. don't get confused and put upstream changes in the Debian diff file or vice-versa). Even if you do get this wrong, it is still easy to fix, just release a new upstream version. Some people don't want to do worry about this, so these people can use native format, and not have to worry about the extra diff file. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so -> Brian> libfoo.so.2.1 For everyone concerned: versions of libtool already support this. eg. cvs version of libtool 1.4, and cvs tree for libtool 1.3x (not sure if includes the latest release of libtool or not, it definitely includes the libtool CVS version under projects/experimental, as Heimdal already uses the new system). lrwxrwxrwx1 bam users 14 Feb 5 12:36 libl4.so -> libl4.so.0.0.0* lrwxrwxrwx1 bam users 14 Feb 5 12:36 libl4.so.0 -> libl4.so.0.0.0* -rwxr-xr-x1 bam users 12970 Feb 5 12:36 libl4.so.0.0.0* which is exactly what was proposed here. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Marcelo" == Marcelo E Magallon <[EMAIL PROTECTED]> writes: Marcelo> Jason's is actually a valid question concerning this Marcelo> thread. Well, sorry if I misunderstood the question, but I interpreted it as "why does libltdl need libx.la instead of loading libx.so directly?" Well, when libltdl loads libx.la, it knows that libx.so depends on liby.so, so it can load that library too. (Also it is more consistent because some OS don't support library interdependencies) So now we start heading off topic with questions like: "why can't the interdependencies be included directly in libx.so?" which are answered with answers like "because current versions of libtool have problems dealing with library interdependencies". So, as I said before, I don't see how any of this is relevant to the original bug report by Ian, so I didn't discuss it earlier. Then again, I now realize that *.la files conflicting is a totally separate issue, so I probably should have bought it up at a different time. -- Brian May <[EMAIL PROTECTED]>
Re: Native packages, broken uploads, and debian policy
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> The you should not be surprised by my continued Manoj> disagreement with your analysis. I think you may not have read my later messages where I changed that to "I agree". Manoj> If nothing else, the changelog needs to be modified to Manoj> reflect that the package was rebuilt, and certainly Manoj> conflicts need to be introduced against the bad version Manoj> numbers of the buggy library. No. Not necessarily the case. The maintainer doesn't have any say over what libraries are used when the autobuilders compile the code. This is an autobuilder issue, and maintainers shouldn't have to do any work if the autobuilder makes the wrong choices. Why should the maintainer have to upload a new version of the code, just because the libncurses5 library on sparc is broken and only causes problems of sparc? Or, say there is a serious problem with glibc on platform X - do you expect maintainers of all packages to upload a new package with a new changelog entry just so packages will compile against the new library? Also, realize that for the above cases, the maintainer may have compiled the package for his/her favourite platform using non-buggy libraries, so that the actual uploaded code has no problems. The autobuilders can already handler this situation fine (from what I have heard) - don't change it. Manoj> I see no need to introduce a whole new syntax for Manoj> packages to accomplish this; we already have a means for Manoj> decoupling the packaing code from the rest of the code. See my latter message - I am not disagreeing with you. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Frank" == Frank Belew <[EMAIL PROTECTED]> writes: 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 to have the -dev Frank> package installed as well. How many packages use *.la files for run time? 1? Under 5? Under 10? My guess is that the number of packages is so small, that the best solution might be to separate the *.la and *.so files into a separate package (I think the *.so sym-link is required too)[1]. That way, multiple versions of the library don't conflict and can be installed at the same time, but normal users don't have to install the -dev package either. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#83669: Shared libraries
>>>>> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: Jason> Does anyone know *why* libtool requires this? It strikes me Jason> as totally unnecessary for runtime linking on linux. Maybe Jason> someone should fix libltdl. Lets not get off-topic into a flame war over "why does libtool do it this way?" please. This thread&bug report is on a specific proposal to allow compiling of programs against one version of the library, while another version is used for run-time. (same major version). -- Brian May <[EMAIL PROTECTED]>
Re: Native packages, broken uploads, and debian policy
>>>>> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes: Henrique> Ok. So you propose we forbid debian revision numbers for Henrique> SOURCE native packages, but allow them for binary-only Henrique> NMU's ? Agreed. Henrique> Seems fine to me. That would allow the issue with broken Henrique> non-native uploads to be fixed, and allow binary uploads Henrique> of native packages using a debian revision number, if Henrique> one wants to. -- Brian May <[EMAIL PROTECTED]>
Re: Native packages, broken uploads, and debian policy
>>>>> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes: Henrique> On Sun, 04 Feb 2001, Brian May wrote: >> Although for native packages (which should not already have a >> Debian revision number), -# should probably be appended >> instead, so the version stays the same. Henrique> No. That is the same as adding a Debian revision (native Henrique> packages are forbidden to have '-' in their version Henrique> strings, UNLESS there is another '-' in there defining a Henrique> debian revision field). No! I mean for binary deb packages only, where a rebuild is required, eg. for a new version of the package. So, the maintainer would upload x-0.5.7.tar.gz x-0.5.7.dsc x-0.5.7_i386.deb however, when the autobuilder realizes that this needs rebuilding, eg for a new version of libc6, it creates x-0.5.7-1_i386.deb instead of x-0.5.7_i386.deb (not allowed; apt-get wont down-load it as the version is the same) or x-0.5.7.0.1_i386.deb (changing the version number like this is stupid, and not even required.) this is no different to the autobuilder playing around with the Debian revision number for non-native packages. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Frank" == Frank Belew <[EMAIL PROTECTED]> writes: 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 to have the -dev Frank> package installed as well. In that case, consider a possible solution: libx.la is renamed by debian/rules to libx.la.1.2.3 At postinst of non-dev package: ln -sf libx.so.1.2.3 libx.so.1 ln -sf libx.la.1.2.3 libx.la This way neither libx.so.1 or libx.la will conflict. The sym-link is adjusted/removed, as required when the package is removed. However, (I need to check this) libx.la needs to refer to the oldest library (oldest minor version; major version is the same), and libx.so.1 needs to refer to the newest library, this is so things will work correctly for link-time and run-time. (probably some dh_* helper program would do this stuff automatically so individual maintainers do not have to worry.) -- Brian May <[EMAIL PROTECTED]>
Re: Native packages, broken uploads, and debian policy
>>>>> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes: Henrique> IMHO we should solve the dillema of adding revision Henrique> numbering to .orig.tar.gz first (due to package pools), Henrique> and maybe include in that solution this idea of Henrique> yours. But this is somehow outside the scope of this Henrique> thread. Henrique> As for autobuilders, binary NMUs and NMUs, the present Henrique> solution (append .0#) to the full version number Henrique> (upstream + debian revision, if it exists) works and Henrique> causes no source headaches for the vast majority of the Henrique> packages. Agreed. Although for native packages (which should not already have a Debian revision number), -# should probably be appended instead, so the version stays the same. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> However, this exposes other issues, since the version of
Brian> *.la required depends on the version of the library
Brian> required, however only one copy of the *.la file can be
Brian> installed, while a number of different versions of the
Brian> shared library can be installed at the same time.
I have done a bit more research on this topic (further results still
to come), and it seems that the *.la file won't be so much a problem
as I originally though - just put it in the -dev package, and
everything should be fine.
In theory, the *.so file could be a problem. Are there any packages
that link to libx.so.2, and then try to dlopen("libx.so")? If so, then
the dlopen might use the wrong version of the library. I can't imagine
why a program would want to do this though, and even if it does, it
seems the solution is to use libltdl to dlopen("libx.la") instead,
which will automatically do the right thing (that is use the latest
version of the library).
--
Brian May <[EMAIL PROTECTED]>
Re: Native packages, broken uploads, and debian policy
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> I feel that native packages should not have a debian Manoj> revision, but not strongly enough or with reasons to be Manoj> able to convincingly argue that feeling be made mandatory Manoj> in policy. I disagree. The problem here is that the Debian version serves two tasks: 1. has the package changed from the upstream version? 2. has the package been rebuilt? So obviously 1 is not relevant but 2 still is. eg. consider a package that was built against a buggy library, and the package has to be rebuilt in order to fix the problem. No source needs to change, so updating the version number is (IMHO) an overkill. Then again, the current solution isn't very optimal either. As changing the Debian revision number requires changing the name of the source file, even though the source file has not changed. --- I would suggest we have either 1: non-native packages (no change): /home/bam/source/notmine/libpam-heimdal_1.0-8.diff.gz /home/bam/source/notmine/libpam-heimdal_1.0-8.dsc /home/bam/source/notmine/libpam-heimdal_1.0-8_i386.changes /home/bam/source/notmine/libpam-heimdal_1.0-8_i386.deb /home/bam/source/notmine/libpam-heimdal_1.0-8_i386.upload /home/bam/source/notmine/libpam-heimdal_1.0.orig.tar.gz native packages: /home/bam/source/notmine/libpam-heimdal_1.0.dsc /home/bam/source/notmine/libpam-heimdal_1.0-1_i386.changes /home/bam/source/notmine/libpam-heimdal_1.0-1_i386.deb /home/bam/source/notmine/libpam-heimdal_1.0-1_i386.upload /home/bam/source/notmine/libpam-heimdal_1.0.orig.tar.gz so no diff is required (as no changes to source code should occur), but a Debian revision number is used to identify the binary, so it can be recompiled. --- or 2: non-native packages (no change): /home/bam/source/notmine/libpam-heimdal_1.0-8.diff.gz /home/bam/source/notmine/libpam-heimdal_1.0-8.dsc /home/bam/source/notmine/libpam-heimdal_1.0-8!1_i386.changes /home/bam/source/notmine/libpam-heimdal_1.0-8!1_i386.deb /home/bam/source/notmine/libpam-heimdal_1.0-8!1_i386.upload /home/bam/source/notmine/libpam-heimdal_1.0.orig.tar.gz native packages: /home/bam/source/notmine/libpam-heimdal_1.0.dsc /home/bam/source/notmine/libpam-heimdal_1.0!1_i386.changes /home/bam/source/notmine/libpam-heimdal_1.0!1_i386.deb /home/bam/source/notmine/libpam-heimdal_1.0!1_i386.upload /home/bam/source/notmine/libpam-heimdal_1.0.orig.tar.gz (replace ! with more appropriate character) so the two separate tasks for the Debian revision number are clearly split apart. This method means that the version for the diff filename does not change if the package is simply rebuilt. I suspect this might have certain implications for autobuilders too, for the same reasons. ie. it is possible to rebuild the package for a particular architecture without hacking around with the version number. I would recommend this solution. -- Brian May <[EMAIL PROTECTED]>
Re: Is the stable/unstable split broken?
>>>>> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes: Matthew> If you're thinking of creating a meta-package called Matthew> 'stable' which depends on the stable version of every Matthew> package, typing apt-get upgrade stable will install every How big would the depends: line get? then again, don't answer that... Matthew> single package listed therein. Does anyone else have a Matthew> problem with that? I suppose that is meant to be the difference between apt-get upgrade stable and apt-get install stable ? -- Brian May <[EMAIL PROTECTED]>
Re: Is the stable/unstable split broken?
>>>>> "Russell" == Russell Nelson <[EMAIL PROTECTED]> writes: Russell> I propose that Debian eliminate the concept of the stable Russell> vs unstable distributions, and instead have a Russell> meta-package called "stable". If I say "apt-get upgrade Russell> stable", that upgrades me to the latest version of Russell> stable, which of course also fetches all the packages it Russell> depends on. If I understand correctly, you want to be able to: apt-get install stable(to install stable) apt-get install xyz (to install the latest unstable version of xyz) the second operation would automatically remove stable - not good... Think of security updates for stable. Also, what happens if I were to type in: apt-get upgrade would that automatically replace all packages on my mostly stable system with unstable packages? Have you looked at the new features in the new version of apt (CVS version, or has that been released now?). They might already address the problems you want to fix. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> So? This makes things consistent, and much easier to track Ben> bugs and problems. Your proposal would make things really Ben> difficult to track bugs "The bug only shows up when I have Ben> libfoo1_1.0 and libfoo-dev_0.9 installed". This puts too much Ben> load on the maintainer. If done properly, the maintainer only need to know if the user is trying to compile an application (libfoo-dev is used) or trying to run an application (libfoo1 is used). Might be confusing the package a is compiled based on an older version of libfoo-dev, but executed with the newer version of libfoo1, but still it should be easy to realize what is happening (just stick to the previous rule). *.la files will be a problem, as explained in my other message. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Marcelo" == Marcelo E Magallon <[EMAIL PROTECTED]> writes: Marcelo> I don't think I understand what you mean by manage here. Marcelo> You can't prevent users from running 'ldconfig'. If you Marcelo> run 'ldconfig' it will read the sonames and place Marcelo> symlinks to the "newer versions" of the library. This is only a problem if it modifies the symlink used for compilation (libfoo.so). It doesn't matter about the other symlink (libfoo.so.2), as this is used at run time, and the newer minor-versions of the library are meant to be 100% backward compatible with existing source (otherwise the major number would be incremented). That is, if my understanding is correct (please correct me if I am wrong): 1. If you delete a function in the library: => might break existing programs => increase major version 2. If you add a new function in such a way that old software will continue to work: => existing programs won't break => increase minor version => programs compiled for this new version won't work with the old version This I believe is standard libtool behaviour (although I haven't double checked) although libtool has uses different terms. For the 2nd case, you can't just increment the major version, this will break existing software, even though the library is backward compatible. I hope that clears up some confusion over version numbers (which admittedly I am only just beginning to understand myself). -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Marcelo" == Marcelo E Magallon <[EMAIL PROTECTED]> writes:
Marcelo> libfoo-dev (2.1-1) was compiled with libbar-dev (1.1-1).
Marcelo> libbar1 (1.1-1) exists in unstable and libbar1 (1.0-1)
Marcelo> exists in stable. Due to bad judgement, libbar1 (1.1-1)
Marcelo> (and libbar-dev 1.1-1 according to this proposal)
Marcelo> contains one extra function (wrt to 1.0-1) which
Marcelo> libfoo-dev (2.1-1) uses. That means libfoo-dev (2.1-1)
Marcelo> depends on libbar1 (1.1-1), or is it libbar-dev (1.1-1)
Marcelo> according to this proposal?
Lets take your example (before hand we would have considered libfoo
as an application, not a library, but this will still work):
There are two cases:
1. programs that compile using libfoo2 do not use functions from libbar1
stable
--
libbar1(1.0-1)
libbar-dev (1.0-1) depends libbar-dev (=1.0-1)
libfoo2(2.1-1) depends libbar1
libfoo-dev (2.1-1) depends libfoo-dev (=2.1-1)
unstable
libbar1(1.1-1)
libbar-dev (1.1-1) depends libbar-dev (=1.0-1)
libfoo2(2.1-1) depends libbar1(>= 1.1-1)
libfoo-dev (2.1-1) depends libfoo-dev (=2.1-1)
I will assume libfoo2 does not need to be changed, because it can
check if the new function exists or not using a configure test.
Remember, that libfoo2 will correctly have the correct "depends:" as
this comes from the shlibs information in libbar1 (which I assume to
be correct).
2. programs that compile using libfoo2 require functions from
exactly the same version of libbar1 (consider the case where libbar1
is glibc, and *is* be important)
AFAIK It is not possible to set the build-depends automatically to the
correct value, but this is a problem with the existing build system,
and this proposal doesn't change that limitation in anyway, in fact,
this example is based on the existing system (it should really be
determined based on the version of libbar1 used).
Marcelo> And exactly what do you want to do with the soname in
Marcelo> libfoo.so? You can't just hide it from ldconfig, can
Marcelo> you?
Don't you mean libbar1? Now you have got me confused.
--
Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: I previously misunderstood Herbert's proposal, here it is again (I hope it is accurate this time...). foo2.0 (2.0) /usr/lib/libfoo.so.2.0 (actual library) Provides: foo2 version 2.0 foo2.1 (2.1) /usr/lib/libfoo.so.2.1 (actual library) Provides: foo2 version 2.1 foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so -> libfoo.so.2.1 the maintainer scripts for foo2.0 2.0 would create /usr/lib/libfoo.so.2 -> libfoo.so.2.0 while the maintainer scripts for foo2.1 2.1 would create /usr/lib/libfoo.so.2 -> libfoo.so.2.1 That IMHO is probably the best suggestion I have seen so far. Just as long as foo2.1 doesn't conflict with foo2.0 (otherwise you get no benefit)[1]. Data files (eg plugin modules, see libgii0 potato version), may be an issue here. If both foo2.0 and foo2.1 both contain the same data file, they will conflict. Fix (1): put data files in a separate package. Fix (2): if the run-time library requires specific version of the datafile, then the data file needs to be made unique in some way, eg. put in a unique directory. (so multiple versions of the data file can be installed at once). (a combination of these may be used). However, neither of these solutions will help with *.la files that are required at run-time. From the debian-policy, 11.2: "Packages that use libtool to create shared libraries should include the .la files in the -dev packages, with the exception that if the package relies on libtool's libltdl library, in which case the .la files must go in the run-time library package. This is a good idea in general, and especially for static linking issues." However, if foo.la file goes into the run-time foo2.0 and foo2.1, then these packages will conflict. Solution: Fix (1), as above. However, this exposes other issues, since the version of *.la required depends on the version of the library required, however only one copy of the *.la file can be installed, while a number of different versions of the shared library can be installed at the same time. Fix (2) could be used here, but this breaks the existing libtool conventions. Note: [1] IMHO the policy suggests that it should be possible to install multiple versions of the library at the same time, but does not require it: "If you have several shared libraries built from the same source tree you may lump them all together into a single shared library package, provided that you change all their sonames at once (so that you don't get filename clashes if you try to install different versions of the combined shared libraries package)." -- Brian May <[EMAIL PROTECTED]>
Re: Bug#83669: Shared libraries
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> Hi, We seem to be balancing 300MB for all archives, Look at Herbert's proposal - it doesn't require any extra space, except for storing multiple versions of the library (which could be done privately too, if Debian doesn't want to do it). -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes: Henrique> In other words, if this bug is deemed to be correct, we Henrique> will have to add hard-link support to dpkg and Henrique> .debs. Anything else will simply DOUBLE the already Henrique> bloated */lib and the archive. Such doubling is NOT Henrique> acceptable (IMHO, but it seems that at least BenC agrees Henrique> with me). hard-link support will not help any more then sym-links currently do. -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes: Herbert> Ian Jackson <[EMAIL PROTECTED]> wrote: >> Currently, wrt shared libraries, we mandate (or do) this: >> foo2 (2.1) /usr/lib/libfoo.so.2 -> libfoo.so.2.1 >> /usr/lib/libfoo.so.2.1 (actual library) >> foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so -> >> libfoo.so.2 Herbert> How about /usr/lib/libfoo.so -> libfoo.so.2.1 and allow Herbert> shlibs with different minor version numbers to be Herbert> installed together by encoding it into the package name. Herbert> Of course, we'll have to manage /usr/lib/libfoo.so.2 Herbert> dynamically as well. Seems like a good idea, but it won't work. foo2 (2.0) /usr/lib/libfoo.so.2 -> libfoo.so.2.0 /usr/lib/libfoo.so.2.0 (actual library) foo2 (2.1) /usr/lib/libfoo.so.2 -> libfoo.so.2.1 /usr/lib/libfoo.so.2.1 (actual library) foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so -> libfoo.so.2.0 the problem here is that the two versions of foo2 cannot be installed at the same time (1: conflicting package name; 2: conflicting symlink). However, if you really wanted to, you could have foo2_0 (2.0) /usr/lib/libfoo.so.2.0 (actual library) foo2_1 (2.1) /usr/lib/libfoo.so.2.1 (actual library) foo2 (2.0)/usr/lib/libfoo.so.2 -> libfoo.so.2.0 foo2 (2.1)/usr/lib/libfoo.so.2 -> libfoo.so.2.1 foo-dev (2.1) /usr/lib/libfoo.so -> libfoo.so.2.0 which means that multiple minor versions of the library can be installed at the same time, and the version of foo2 determines which one to be used for run-time, while foo-dev determines which one should be used for compilation. foo-dev is independent of foo2. People might complain about foo2 (do we really need a package containing nothing but a symlink?), but personally I like the idea (compare with task packages which are empty). I think it is simple to understand, and adds little overhead (just foo2). Packages work as normal (installing foo2 2.1 or foo-dev 2.1 for instance would automatically install foo2_1). Comments? -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> In general, it's not safe to use a minor version of a library Ian> lower than that with which the binary was compiled. Ian> So you if you have a library L used by both an program S Ian> which you want to compile for stable and a program U you want Ian> to try out from unstable, then you have to install the L from Ian> unstable (because U is compiled against it), and because the Ian> versions of L and L-dev have to match, you have to have the So lets make up some more details: stable: -- libl6 version 2.1-1 contains: /usr/lib/libl.so.6.0 /usr/lib/libl.so.6 --> /usr/lib/libl.so.6.0 libl-dev depends on libl6 version 2.1-1 and contains: /usr/lib/libl.so --> /usr/lib/libl.so.6.0 progs depends on libl6 and contains: ldd /lib/libwrap.so.0 libc.so.6 => /lib/libc.so.6 (0x4000e000) libl.so.6 => /lib/libl.so.6 (0x) -- unstable: - libl6 version 2.2-1 contains: /usr/lib/libl.so.6.1 /usr/lib/libl.so.6 --> /usr/lib/libl.so.6.1 libl-dev depends on libl6 version 2.2-1 and contains: /usr/lib/libl.so --> /usr/lib/libl.so.6.1 progu depends[1] on libl6 (>=2.2-1) and contains: ldd /lib/libwrap.so.0 libc.so.6 => /lib/libc.so.6 (0x4000e000) libl.so.6 => /lib/libl.so.6 (0x) - so progs will work with both versions of libl.so.6.* but progu will only work with libl.so.6.1, as it was compiled based on libl.so.6.1 And you want to install libl-dev version 2.2-1 on a stable system without installing libl6 version 2.2-1 at the same time? Am I right so far? If so, what is the problem with installing the unstable version of libl6? Oh, you explain it here. Ian> L-dev from unstable, but then when you compile S it ends up Ian> needing the L from unstable. So you want to be able to compile progs based on libl version 2.1-1 and progu based on libl version 2.2-1. You don't want to have to downgrade libl to version 2.1-1 just to install libl-dev 2.1-1, because that would break progu. Your proposal would (supposedly) help by allowing you to install libl-dev version 2.1-1 even though libl6 version 2.2-1 has been installed, so you can compile for the earlier version, while at the same time you can run both progu and progs. (how do you ensure that all -dev packages installed are from stable, and you haven't missed any?) Ok, Thanks, I think I understand now. Note: [1] I hope nobody disputes why this version depends is required... (things might get awkward if it was forgotten). -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Seth" == Seth Arnold <[EMAIL PROTECTED]> writes: Seth> How does this work with the glibc mess I seem to recall from Seth> about a month ago? I don't recall the details - can somebody please give me a URL? -- Brian May <[EMAIL PROTECTED]>
Bug#83669: Shared libraries
>>>>> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> The effect is that foo-dev (2.1) has to have a dependency on Ian> foo2 (2.1) because otherwise you might compile against a .so Ian> file and headers from different versions. Ian> This is bad because it makes it hard to upgrade your runtime Ian> environment to run new versions of things without also making Ian> your compilation environment generate new and incompatible Ian> binaries. I am afraid I don't see the problem. When a new version of the library is released that has incompatible changes, it should be released as libfoo3. Even after libfoo3 is installed, programs will continue using libfoo2 without any problems until they are recompiled for libfoo3. The problem is? You seem to imply that the versions of the libraries are incompatible, despite having the same major version. If this is really the case, I think the potential exists to break a lot more then just the build process. Please give me a real life example of why distinguishing libraries solely by their major version number is not good enough... -- Brian May <[EMAIL PROTECTED]>
Re: Path modification
>>>>> "Moshe" == Moshe Zadka <[EMAIL PROTECTED]> writes: Moshe> U.that doesn't strike you as a weird error message? Moshe> Especially since the shell thinks "mh" *is* a valid Moshe> completion? I expect things that are valid completions to Moshe> work. I agree with this. Especially for directories (it should be easy to check if a executable file is just a directory or really is executable). Symlinks might be slightly harder (but still possible all the same): (zsh) [620] [snoopy:bam] ~ >X11 zsh: permission denied: X11 [621] [snoopy:bam] ~ >which X11 X11 not found I assume it is looking for [622] [snoopy:bam] ~ >ls -l /usr/bin/X11 lrwxrwxrwx1 root root 12 Dec 29 16:43 /usr/bin/X11 -> ../X11R6/bin/ (IMHO if the shell can find /usr/bin/X11, which should also find it too, but I guess that might break things. However, I guess the fact that which knows it is not an executable clearly shows that the shell should be able to work it out for tab completion, too). -- Brian May <[EMAIL PROTECTED]>
Re: changelog bug-closing should not be used unless the code changes
>>>>> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes: Chris> I'm not sure I agree with the much-more-friendly part. I'd Chris> rather see a descriptive changelog entry than a terse and Chris> uninformative separate email. Basically, I'd say Chris> friendliness has more to do with style than with delivery Chris> mechanism. I think it is harder on the bug submitter to find out why the bug was closed. First you have to wade through the changelog entries to find the one relevant to the bug you submitted, Chris> I might even go so far as to suggest that we should Chris> deprecate all other methods of closing bugs, and use the Chris> changelog entries as our *preferred* bug-closing mechanism. Chris> Therefore, if Ian is making a policy proposal, I firmly Chris> oppose it. Sometimes you can close a bug straight away - eg. if the bug was filed in mistake, or a non-bug, etc. You don't always want to wait until the next package release just so you can close a bug. -- Brian May <[EMAIL PROTECTED]>
Re: changelog bug-closing should not be used unless the code changes
>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> Just to comment on this little bit, I think it is Ben> appropriate, because then the package's changelog serves as Ben> sort of a FAQ if the issue is ever brought up again (and the Ben> bug has expired from the BTS). It also keeps an historical Ben> reference for decisions. Just my 2 cents: I thought the Changelog was used to record changes in the package. Since when has the role of the Changelog also expanded to include the role of the FAQ? Surely, any questions like this belong in another file, FAQ.txt, nonbugs.txt, or something, not the Changelog? Who knows, perhaps we could mandate in policy "all users should check the file /usr/share/doc//faq.txt before reporting a bug in case the maintainer thinks it is a non-bug"[1]. Only this is restrictive, it means a new package has to be released before the faq.txt can be updated. How about allowing maintainers to edit an area under http://packages.debian.org.au/ which deals with common problems users may have with the package? (I think this has been suggested before). That way, users don't have to scan the entire BTS history for the package to find out if the problem has either been reported before. Otherwise, you will end up with the full documentation appearing in the Changelog, which is not the intended purpose of the Changelog. -- Brian May <[EMAIL PROTECTED]>
Re: P.S. [mirian@cosmic.com: Re: A Linux Elbows - flavors]
>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> Huge monolithic patch files like this are just fucking Raul> useless, and the debian/changelog is no help because it Raul> doesn't cross reference the patches incrementally, as cvs Raul> does. I like the method used in openldap (at least in woody), and now in heimdal, and (to a certain extant) libpam-heimdal. For heimdal, in particular, I found myself making so many completely different and unrelated changes, I found it impossible to manage with CVS Was this file different due to a upstream bug, or was it different because I wanted to try and use installed Debian shared libraries, or was it different because of changes I had to make for the FHS? The problem with CVS is that I might be in middle of making one big change, when I have to make a minor changes to other parts of the code. So relying on tags and/or dates to distinguish between changes won't always help. Perhaps appropriate use of branches might help, but I don't think it is worth the effort. So, for now I have dropped using CVS, and have a single patch file which represents each problem. As an advantage, I can easily send to upstream a single patch file if I think the problem should be fixed upstream. The only real dislike is the lack of tools to manage this setup. eg. I would like tools (should be easy to write) that do simple tasks like: 1. unpack source here, apply patches up to an including X, and make copy using "cp -a" or "cp -al" (copying hard links is better but does not work unless the program breaks the link; some don't, including autoconf, automake, and my setup of vim). 2. diff new source with old source and save result as debian/patches/. 3. Some way to upgrade to a new upstream version and deal with patches that won't apply for some reason. (I find it very tedious to have to look at each reject file to find out what went wrong. I don't always understand the reject file either). I have: 4. I script (specific to heimdal) that will automatically obtain the diff required to update automake and autoconf files (heimdal requires the CVS version of automake and autoconf in project/experimental, so I probably can't depend on this package for woody). -- Brian May <[EMAIL PROTECTED]>
Re: source package structure
>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> [This is not about source package format.] Currently, the Raul> debian/ directory goes inside the source directory, and we Raul> sometimes can't use pristine upstream sources because they Raul> don't conform to our standards. Raul> The obvious way to fix this is: have a standard for the Raul> debian source directory, and unpack the pristine upstream Raul> sources into it. Raul> Note that if we went this direction (and doing this right Raul> would involve some careful planning), this would also Raul> address current silliness, like debian/rules creating .deb Raul> files, etc. in the parent directory. Raul> Here's a draft idea, please poke holes in it: I have comments, first step is to understand the proposal though. Raul> [1] keep current directory naming convention. [2] keep Raul> debian/ as a sub directory of main directory. [3] unpack Raul> pristine sources in the source/ directory [4] Where upstream Raul> sources include a debian/ directory, implement as active Raul> debian/ directory using a symlink. [5] distribute the Raul> debian directory as small, independent tarball. Even where Raul> it's just a symlink. [6] generated files (.deb, .tar.gz, Raul> .dsc, etc.) should all be created inside the main directory, Raul> but outside the debian/ and source/ directories. [7] Raul> migrating to this standard should be associated with a new Raul> major release of policy (with all the associated delays -- Raul> we're going to have some delays anyways just waiting for our Raul> build tools to be able to recognize and deal with this.). Trying to understand this directory structure (do I have this correct?): xyz-0.0/ [1] xyz-0.0/debian/ [2] could be symlink to source/debian [4] xyz-0.0/source/ [3] pristine source tar -C xyz-0.0 -cvzf debian.tar.gz debian [5] xyz-0.0/debian.tar.gz[6] xyz-0.0/xyz_0.0-1.deb xyz-0.0/xyz_0.0-1.diff.gz xyz-0.0/xyz_0.0-1_i386.changes xyz-0.0/xyz_0.0-1_i386.dsc xyz-0.0/xyz_0.0.orig.tar.gz You say that this isn't meant to change the source code format, but [2], [4] and [5] seem to be saying otherwise. -- Brian May <[EMAIL PROTECTED]>
Bug#77404: New virtual packages
retitle 77404 [ACCEPTED] New virtual packages thanks I believe that these can now be included in the virtual package list: -- start of list -- telnet-server Any telnet server rsh-server Any rsh server telnet-client Any telnet client -- end of list -- Note: ftp-client Any ftp client was also included in the initial proposal, but more thought is required in how to define an "ftp" client, or if to rename it to traditional-ftp-client. IMHO this should include any package that comes with /usr/bin/ftp (ideally via update-alternatives). Anybody wanting to discuss this should probably open up a new bug report against debian-policy. -- Brian May <[EMAIL PROTECTED]>
Re: [PROPOSAL] Full text of GPL must be included
>>>>> "Frederico" == Frederico S Muñoz <[EMAIL PROTECTED]> writes: Frederico> I hope there is an easy way to fix this. IMHO, Some people seem to be confusing two issues: 1. is it legal to use a package with other operating systems? YES. 2. does Debian support using packages with other operating systems? NO. The fact that the license says packages can be used anywhere is irrelevant, the packages have been hard-coded and compiled for Debian systems. Testing these packages on other operating systems simply is not a priority (at least as far as i am concerned) for us Debian developers. This means work is required to make the deb package work on a non-Debian system, and programs like alien[1] may or may not do the entire job (eg. the copyright file may refer to a file that doesn't exist). This, IMHO, is no different to other issues that are different between operating systems, such as different interpretations of the FHS. Note: [1] Perhaps an possible alternative would be if alien could automatically insert the correct copyright when converting the package? This needs some reliable way of detecting the copyright though (grep /usr/doc/package/copyright?). -- Brian May <[EMAIL PROTECTED]>
Re: Use $DEB_BUILD_DIR rather than parent directory?
>>>>> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes: Wichert> Previously Eric Gillespie, Jr. wrote: >> Does it? Why not just have dpkg override that final parameter >> with $DEB_BUILD_DIR? If someone sets this variable, they >> clearly want the files to go there and not '..'. Wichert> No tool should try to second-guess the user. Depends if you define user as the "packager" or the "compiler". I am not sure if you are arguing for or against the change here. I would argue (although I don't feel strongly about this) that it should be the "compilers"[1] choice, and not the "packagers" choice. I would also argue that the "packager" shouldn't try to second guess the requirements of the "compiler", because the packager has no way of knowing how the "compiler" likes to organise their source code. IMHO: This proposal is similar to others, eg. for the EDITOR environment variable, where it was decided that the end user should have the final say. The only difference here, is that patches to upstream code are not required. Note: [1] argghh! what should I call the "compiler" (person doing the compilation) so it doesn't get confused with the C compiler? -- Brian May <[EMAIL PROTECTED]>
Bug#77404: Proposed: task-secure-system package
>>>>> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: Bernd> On Sun, Nov 19, 2000 at 01:02:42PM +1100, Brian May wrote: >> telnet-server Any telnet server Bernd> So dou u want to make the task-secure-system package Bernd> conflict with telnet-server? Since we also have secure Bernd> telnet severs (telnetd-ssl). So the problem is we want to Bernd> make sure that task-secure-system also removes insecure Bernd> packages (at least suggests you too) but does not block the Bernd> sysadmin who knows what he is doing, right? This isn't exactly related to the task of creating the virtual packages, however I imagine task-secure-system would still conflict with telnetd. This would allow installation of heimdal-servers, which also provides a secure telnet (assuming you use Kerberos authentication...). The virtual package name isn't required here, as there is only one implementation of telnet (well... AFAIK and as far as this discussion is concerned) that doesn't support secure connections. -- Brian May <[EMAIL PROTECTED]>
Bug#77404: Proposed: task-secure-system package
Package: debian-policy >>>>> "jae" == Jürgen A Erhard <[EMAIL PROTECTED]> writes: >>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> (now I wonder when I created rsh-server and ftp-server, why Brian> I didn't say ftp-client and telnet-server, too - at least Brian> thats the way I remember it). jae> I guess you followed the RULE: virtual packages are only jae> created on "we need it" basis (as outlined in jae> debian-policy/virtual-package-names-list.text.gz). And jae> ftp-client/telnet-server weren't needed, so you didn't create jae> them. jae> Which is, IMHO, a pretty stupid policy... a feature-based jae> thing (with compatible interfaces, of course) would be more jae> logical. Think about what might be needed, not just what jae> *is* (when I buy a new HD, I don't buy just enough so what I jae> need now fits, I buy in anticipation of future needs (and jae> according to what I can afford ;-) Agreed. I wish to create the following virtual packages: telnet-server Any telnet server ftp-client Any ftp client rsh-server Any rsh server The following virtual package should exist (according to the changelog), but doesn't: telnet-client Any telnet client To go along side these already existing virtual packages: ftp-server Any ftp server rsh-client Any package that provides an rsh client Justification: 1. See above text. 2. rsh-server: A number of packages depend on rsh-server, and I think the version in heimdal-clients is also sufficient. This requires a virtual package. 3. telnet-server: means each telnet server only needs to conflict with "telnet-server" and not have to name each individual server. 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). -- Brian May <[EMAIL PROTECTED]>
Re: RFC: allow output from maintainer scripts
>>>>> "Anthony" == Anthony Towns writes: Anthony> Which will kludge up postinsts from now to forever, be an Anthony> extra source for bugs, and make changing things in future Anthony> awkward. I don't think we should downgrade the capability of future debian products, either just for the sake of back-words compatibility. Anthony> Compare and contrast to the usr/doc boilerplate, eg: when Anthony> it goes away, nothing will break, you'll merely have Anthony> mixed documentation if you do a partial upgrade. If the Anthony> above boiler plate ever goes away, new .debs will not be Anthony> installable with an old dpkg. Like the usr/doc situation, after a while we can get rid of the extra stuff. I can't help but think though that this indicates a bigger problem in our reliance on maintainer scripts - it is not possible to add new features without: - hard-coding the entire feature in the maintainer script AND/OR - depending on another package which codes the feature. Not sure on the best solution. Here is one that comes to mind: Perhaps some general system could be implemented that uses a feature straight away (if it is already installed) or takes some other action if the feature is not installed yet (eg ignoring the request or logging the request for latter in case the feature is installed). Such a mechanism could also be used as a base for update-* -- Brian May <[EMAIL PROTECTED]>
Re: RFC: allow output from maintainer scripts
>>>>> "Anthony" == Anthony Towns writes:
Anthony> dpkg already knows this, and it can already be determined
Anthony> by looking for "Unpacking ..." or "Setting up ...".
>> - current task for this package, as generated by dpkg-log
Anthony> Which is exactly what this would be outputting.
Only the current "dpkg task", not the current "postinst task" or
("subtask" to put it another way).
>> - this list could highlight more important events based on the
>> parameters based to dpkg-log.
Anthony> What events here are so important? Why even bother
Anthony> displaying the ones that aren't important?
You seem to imply that a good system is one which generates no output,
except for what package is being installed, and perhaps what state
dpkg is in when installing it.
Isn't this the very reason people hate Windows or Red-hat installation
programs/scripts? - ie. you can't tell what is happening behind the
scenes.
At least, that is the impression I got listening to other people.
I think a better system would be to let the user decide how much
detailed information he wants to see, and to do this the program needs
to be able to determine the priority of various messages.
ie. similar to why priorities are needed for debconf.
--
Brian May <[EMAIL PROTECTED]>
Re: RFC: allow output from maintainer scripts
>>>>> "John" == John Goerzen <[EMAIL PROTECTED]> writes: John> I think that works well. It's better than requiring a John> separate command, and in fact, one can redirect output of John> commands to stderr anyway for those cases in which you might John> want to log the output of an external program. Requiring John> dpkg-log prevents that. IMHO using the dpkg-log helps structure the output of the task, and what make it easier to have a more professional looking GUI front end. eg such a program could have GUI fields for - current package - current task for this package, as generated by dpkg-log - scroll-able list with STDERR and STDOUT output (eg to catch shell scripting errors). This could be disabled if desired. - this list could highlight more important events based on the parameters based to dpkg-log. Now, if dpkg used a similar method to report "directory not empty" warnings, the GUI could even have an option that allows you to browse the directory, and see if there really is anything important there. Now, this E-Mail is going to open up a new can of worms ;-) -- Brian May <[EMAIL PROTECTED]>
Re: RFC: allow output from maintainer scripts
>>>>> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> I take your earlier point about a daemon maybe hanging as it Joey> restarts, and perhaps a emacs byte-compile can hang Joey> too. Heck, *anything* could conceivably hang. If that Joey> happens though, there are tools like top and ps and strace Joey> that are available to see if it has hung and help track down Joey> what is hanging and why. Would it be possible (practical?) to print a message, only if it takes to long to start? eg: execute-or-print-message --timeout 60seconds --message "Trying to start package..." --command /etc/init.d/package start so, if for instance a daemon has a history of hanging, something can be done to make it easier to debug? -- Brian May <[EMAIL PROTECTED]>
Re: RFC: allow output from maintainer scripts
>>>>> "Anthony" == Anthony Towns writes: Anthony> Well, yes. "Bytecompiling emacs modules: emacs19 emacs20 Anthony> xemacs20" would be useful output, by comparison. How about something like this: Messages should only be displayed on the console if: - it represents a slow task, eg compiling modules (emacs) or compiling ls-R files (latex). Of course, this is a subjective criteria... What is a "slow" task? - it represents a task which could potentially crash the computer (not sure if any actually fall in this criteria???). - it represents a task that alters the state of the computer, eg starting a daemon, or changing a config file. Obviously, this could be debated... Any messages displayed should be brief, and a maximum of one line for each item. Any other messages probably should be done via debconf. Of course, this could do with some refinement, but I think you get the general idea. -- Brian May <[EMAIL PROTECTED]>
Re: All services that require a restart from libc6 upgrade...
>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> Ok, I'm tired of having to track all services that might need Ben> to be restarted after a libc6 upgrade. So here's what I am Ben> going to do. I want to require all packages that need this to Ben> declare a new reply in it's init script. It's very simple, I Ben> check your init script like this: Ben> check=$(/etc/init.d/service nss-check 2>&1 || true) Isn't checking every file under /etc/init.d going to be a bottleneck? How about an alternative: every package that is affected calls: (postinst) libc6_upgrade_register /etc/init.d/package restart (prerm) libc6_upgrade_deregister /etc/init.d/package restart I assume that not many packages will be affected? Or, if libc6 isn't the only package with this problem, a more general solution: (postinst) dpkg_register upgrade libc6 /etc/init.d/package restart (prerm) dpkg_deregister upgrade libc6 /etc/init.d/package restart which is better, as it is more general. libc6 would check what packages have been registered in its postinst script, eg with a similar call to one of the above. (ultimately, for the most general solution, dpkg should support it). -- Brian May <[EMAIL PROTECTED]>
Bug#72980: virtual packages list layout
>>>>> "Josip" == Josip Rodin <[EMAIL PROTECTED]> writes:
Josip> On Mon, Oct 09, 2000 at 12:25:20PM -0500, Steve Greenland
Josip> wrote:
>> > should also contain these virtual packages from the
>> Miscellaneous section: > > pdf-preview Any preprocessor that
>> creates PDF output > pdf-viewer Anything that can display PDF
>> files > postscript-preview Any preprocessor that creates
>> Postscript output > postscript-viewer Anything that can display
>> Postscript files
>>
>> Of what possible use are the "-preview" virtual packages? What
>> would depend on "any prepreprocessor that creates {PDF,PS}
>> output"?
Josip> I'm just as uninformed as you are about this, I just listed
Josip> those along with the other two...
The following packages, in potato, use postscript-preview in
some way.
Package: psptools
Provides: postscript-preview
Package: psutils
Provides: postscript-preview
Package: xpdf-i
Provides: pdf-viewer, postscript-preview
Package: xpdf
Provides: pdf-viewer, postscript-preview
Package: acroread
Provides: pdf-viewer, postscript-preview
No package currently depends/requires/suggests it. pdf-preview is not
used at all. Programs like gv (which can write postscript) and dvips
seem to be missing.
IMHO, the name "-preview" is misleading.
--
Brian May <[EMAIL PROTECTED]>
Re: Preparing Debian for using capabilities: file ownership.
>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> Once they're in the file system, they won't only elevate Raul> privilege. At that point, programs can be denied privilege Raul> (even if the user process has the capability, the program Raul> will drop it). Raul> In practice, this is mostly useful to keep complex programs Raul> unprivileged. [It's one of those closing the gate after the Raul> horses have left kinds of solutions. Better than nothing, Raul> but not by very much.] I don't really like this approach, much. As an example: I think it would be good, for instance, if the *user* could specify that only certain programs can have access to ssh-agent for instance. Giving all programs run by the user ssh-agent access would mean a Trojan horse could damage more then just files on the local computer... However, the policy would depend very much on the users preferences (which might get awkward). For instance, I could think of several different policies: a) only bash gets access to ssh-agent, and its child processes (of course!). Or even better: only ssh processes executed directly from bash get access to ssh-agent. b) only bash, emacs, xemacs, etc. c) only this copy of bash, running in this X-Window, and all child processes. This might be appropriate if the ssh-agent has keys that allow root access to remote accounts. The prompt could be changed to remind the user that this shell has greater then normal privileges. This is one thing which currently concerns with capabilities - that the policy would have to be set by the system administrator/package maintainer, and not the individual users. As, it is the user who knows how much he/she trusts each application, what damage it could cause, and how they plan to use the application. Even better, if you could take/remove capabilities to access individual keys in ssh-agent... This might be easier to implement with Kerberos tickets, which are stored as individual files, and not as a separate process. Raul> Basically, I see some use for privileges, but I don't want Raul> to see us going into any kind of "change everything to take Raul> advantage of this new whiz-bang vaporware" thing. Perhaps the best solution might be: - on login give the shell all capabilities for the given end-user. - allow the shell to deny capabilities, depending on user preference and/or command line prefix, when starting certain executables. eg, thinking aloud: > deny ssh-agent all would deny all future processes access to ssh-agent. > grant ssh-agent --allow-inherent xemacs would grant xemacs, and child processes access. ie it would override the previous command, but only for xemacs. > grant ssh-agent --allow-inherent --execute xemacs would start a copy of xemacs and with the privilege. Could be simplified with an alias. No, whether you consider xemacs a shell or not, and should support the same thing - I don't care. That can come latter (if at all). that way nothing needs to be changed, except: a) the shell. b) setuid executables (because the shell wouldn't be able to grant privileges it doesn't have). Ideally, the commands would be standardised across every shell, in such a way that a global config file (or directory) could be used to setup defaults. -- Brian May <[EMAIL PROTECTED]>
Re: Preparing Debian for using capabilities: file ownership.
>>>>> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> Or, put another way, we're going to have to re-write a lot Raul> of administrative docs to adapt to a capabilities-based Raul> security setup. And then we'll have to do it again for Raul> MAC. ;-) or should that be :-( Raul> [Also: both have extra baggage, but MAC+capabilities looks Raul> like something safer to switch over to than capabilities Raul> without MAC.] Where can I find out more about MAC? MAC is a completely new acronym to me... >> - what is the current status of capabilities in Linux? Last I heard, >> it was so limited that it was next to useless. I hope this has/will >> change. Raul> They're implemented in 2.4, but they're not ready for prime Raul> time. The set of capabilities may change, and ext2fs Raul> doesn't let you do the capability analog to setuid (nor the Raul> inverse -- where capabilities are supressed). Will it be possible to limit individual processes access to individual files? I have a good reason for wanting to do this, but so far, all I can tell is that the list of capabilities is fixed/hard-coded in the kernel and cannot be changed. Raul> Not very practical. Raul> kernel change time != package install time. Raul> Basically, we'd be committing to do a complete sweep of the file Raul> system every time the kernel booted. [Perhaps optimize this by Raul> marking each partition with a stamp indicating what kernel Raul> has swept the partition?] My guess is that supporting both systems could get very messy, very quickly. However, I think supporting both systems might be essential, so that people can get use to the completely different way in which things are done, which-out being "forced" into the change. I can't say much more then that right now until I get a chance to play around with some of this stuff myself. Perhaps enhancing suidregister to support capabilities might be a good first step. -- Brian May <[EMAIL PROTECTED]>
Re: Preparing Debian for using capabilities: file ownership.
>>>>> "s" == s Lichtmaier writes: >> > 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 also change its uid to that of daemon or nobody >> then? I assume capabilities are independent of uid? s> If you change RUID, EUID and SUID to a non-root user, all s> capabilities are cleared. Besides, this is the way it will be s> done when cap. enabled filesystems arrive. Can somebody please clarify this statement for a brain-less idiot like me ;-). What do you mean "all capabilities are cleared"? Is this for the current process? Also, quickly glancing through this thread raises the following issues, which I can't see answers to: - is root still required? If so why and what for? - if files are owned by bin:bin, does this mean root no longer can change them (assuming everything is set up correctly)? - what is the current status of capabilities in Linux? Last I heard, it was so limited that it was next to useless. I hope this has/will change. - is it practical/possible to initially support both systems, but have capabilities as an option that is disabled by default, and only enabled if the administrators knows what he/she is doing. ie could the postinst script have: if ! capabilities; then suidregister ... else set capabilities. endif sorry, I am still confused over capabilities in general, so the above may not really make sense ;-). For instance, I do not understand how processes are initially assigned capabilities. Please consider posting replies to debian-devel. -- Brian May <[EMAIL PROTECTED]>
Re: : Question regarding actions to take on --purge of a package.
>>>>> "Greg" == Greg Stark <[EMAIL PROTECTED]> writes: Greg> That would be clean, but it's not practical, in this case Greg> I'm talking about kerberos and /etc/krb.conf and Greg> /etc/krb.realms. These files are standardized upstream and Greg> we can't start moving them around. I can't remember what /etc/krb.realms is... However, AFAIK, the only conflict in files will be between MIT and Heimdal implementations of Kerberos... Greg> In this case it's not likely to be important because I don't Greg> believe many people used the 0.99 kerberos Greg> libraries. However a similar problem is likely to crop up Greg> shortly between heimdal and kerberos4kth. I don't think so - Heimdal uses: /etc/krb5.conf /etc/krb5.keytab Where the first file is config info that could be stored in DNS instead. The second file contains the private keys for this host, and must be kept secret. I would be surprised if the krb5.conf is compatible with MIT's implementation of Kerberos, however, I think the keytab file should be OK. Don't take my word for it though... Greg> But pretty much any library that has configuration files is Greg> likely to keep the same filenames across multiple Greg> versions. It would be confusing for the user to have custom Greg> filenames just for debian that's different from the names Greg> used for configuration files from the upstream version. Greg> I guess one option is to have a /etc/libfoo.conf.1 and then Greg> link /etc/libfoo.conf to it in the postinst. Then it points Greg> to the most recently installed configuration. I have already noticed this problem with certain packages - I think it has dhcp and dhcp-beta. I installed dhcp, which automatically removed (but didn't purge) dhcp-beta. At a latter date, I purged dhcp-beta. To my surprise, dhcp-beta stopped working. Why? Because the postrm routine deleted the /var/dhcp directory. While it looks like the postrm routine has now been hacked not to delete the directory if any files exist, I don't really like this solution, and think it clearly highlights some of the problems with shared configuration files. Ideally, I don't think the postrm script should delete any files, everything should be managed by dpkg, but I don't think this is going to happen any time in the near future. >>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> In that case, onse should serously consider if Manoj> sumultaneous installation is very useful, since the Manoj> packages seem to be drop in replacements. If it is indeed Manoj> desirable to have more than one version installed Manoj> simultaneously, your solution below seems a decent Manoj> workaround. Personally (and I realize others do disagree), my feeling is: - Kerberos 4 is obsolete and should not be used anymore. MIT no longer support it. There is only one mainstream application that still requires Kerberos 4: AFS. It could be argued that AFS is now obsolete, but AFAIK, no up-to-date open source implementation of DCE/DFS exists :-(. Eventually, I have been told, Arla (open source AFS) will support Kerberos 5. - MIT and Heimdal are mostly[1] drop in replacements, and it would be OK if they conflicted. Manoj> Yes. And one can look into alternatives, espescially Manoj> for heimedahl and MIT kerberos, rather than trying to have Manoj> both packages ahve the same conf file. For /etc/krb5.conf, DNS could be used, for at least some situations. Footnote: [1] programs need to be compiled specifically for MIT or Heimdal. Arrgh! It would be nice if something like SASL could be used to "insulate" programs from having to directly interface with the Kerberos libraries, but this may require making major changes to the code. Still, I think this would be worth the effort... With SASL support, the program will work with any authentication method, not just Kerberos. eg, you could write a SASL module that does ssh like RSA based authentication. No re-compilation required. Not everybody likes Kerberos, and this would be the best way to satisfy everyone. SASL support in Debian would mean we could support both implementations of Kerberos 5, and just use a different SASL module for each one. However, now the subject has changed considerable from what is in the subject line... -- Brian May <[EMAIL PROTECTED]>
Bug#71621: No policy on calling update-alternatives (was Re: update-alternatives)
>>>>> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: Colin> On my system, there are no less than eight distinct ways Colin> used by packages to remove alternatives (excluding Colin> special-case conditions like that used by ae, and folding Colin> down the various ways used to express conditions on $1): I had a proposal to replace these scripts with XML format. However, I haven't got much feedback yet... I think the benefit of my proposal to this particular problem would be that it allows the system administrator to setup the method used by all packages, rather then each individual package maintainer. eg some administrators may want to force the higher priority task to take precedence, where as others may want to preserve the currently installed value. See http://snoopy.apana.org.au/~bam/debian/ for details of my proposal. PS: I will be away next week, so may be delayed in responding. -- Brian May <[EMAIL PROTECTED]>
Re: policy changes toward Non-Interactive installation
>>>>> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> I read your entire message and could not find any examples Joey> of things that debconf cannot handle correctly, except of Joey> course for conffile change prompting, which it was never Joey> designed to do. I think something needs to be done to address this issue. Yes, you can force dpkg to always use the old file, but then this will break applications which require the new file to be installed. -- Brian May <[EMAIL PROTECTED]>
Re: Parseable copyright files (was: Re: Bug#65577: PROPOSED] README.Debian should include notice if a package is not a part of Debian distribution)
>>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: Julian> Copyright: non-DFSG Copyright-non-freeness: # Brief Julian> details of non-freeness here Copyright-Details: # field Julian> with copy of copyright Julian> Comments? Seeing as everything seems to be going XML these days, why not: You must not use this program under any circumstances other then that of wasting time. Nobody else is allowed access to the software, either directly or by sharing looks at the monitor. You must not laugh at the program whenever it crashes. You must encourage others to install this software on their computers. Not that I am not any XML expert, so you might be able to make this better. However, there seem to a wide range of XML parsers available in Debian, for C, Java, Python, and Perl. Note: I have called it license, because I think it is the license we are discussing here, not the copyright... However, why stop at the license? Perhaps the same thing could be done with other information, eg relevant web pages, email addresses, etc. -- Brian May <[EMAIL PROTECTED]>
Re: Crypto and US - the time is nigh
>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> On Mon, May 15, 2000 at 12:45:46PM -0400, Richard A Nelson Ben> wrote: >> I just realized that the sendmail update I made this weekend >> 8.11.0.Beta1 should probably be removed from its home in >> US/Extra/Mail because the source (and binary) has hooks for >> SASL and TLS. Ben> SASL is not regarded as cryptography. It is merely a module Ben> layer, and has no real crypto of it's own. IIRC, the Ben> libcyrus-sasl in woody does not contain any crypto Ben> modules. AFA TLS, did you link against libssl09? If not, you Ben> have nothing to worry about. I believe that is now libsasl... (just to make sure there are no copies of my old package still lying around...) -- Brian May <[EMAIL PROTECTED]>
Re: mail spool (Finale)
>>>>> "Marco" == Marco d'Itri <[EMAIL PROTECTED]> writes: Marco> We have it: Marco> For MUAs: $MAIL. For MTAs: ~/.forward For LDAs: depends on Marco> the program, but it's not really important because you have Marco> to configure it anyway. True, but there is no central place to set $MAIL (and I think $MAILDIR is the correct place for maildirs???). But, this takes us back into the debate on /etc/environment :-( [ Please send followups to the following to debian-devel ] You can set this up in /etc/login.defs, but this only applies (AFAIK) for console and telnet logins, and not ssh. Perhaps, with PAM, something better could be done (if I said why I think this is insufficient though, we would be heading way off topic for this thread). What is an LDA? -- Brian May <[EMAIL PROTECTED]>
Re: mail spool (Finale)
>>>>> "jrfern" == jrfern <[EMAIL PROTECTED]> writes: jrfern> Well, the aliases system in qmail is completely jrfern> different. Should this ammount to a wishlist message to jrfern> the qmail-src maintainer, suggesting a qmail -> jrfern> fastforward dependancy? (this applies to sendmail to qmail jrfern> migration, but not the other way round). Should an jrfern> 'addalias' script be created which wrote both to jrfern> /var/lib/qmail/alias/ and /etc/aliases? I think qmail is the only MTA that doesn't support /etc/aliases (AFAIK), and even this can be supported (last I heard) with add ons, so I shouldn't be discussed further. jrfern> CONCLUSIVE QUESTIONS Is qmail an inherently non-Policy jrfern> packet? Should the Policy wording be modified? Doesn't the jrfern> Policy have a bias for a sendmail-like system? Have the jrfern> security implications been considered (see Bugtraq 1999-1, jrfern> discussion between Venema and Berstein)? Did I miss jrfern> something? jrfern> How about an /etc/mailsystem conffile? For instance (of jrfern> course this is naïve) mta=qmail|sendmail|smail... mda=... jrfern> spool= aliases= mboxformat=mbox|mh folders|maildir... I think it is important to realize that other programs support ~/Mailbox and ~/Maildir now, and not only qmail. Please stop making the assumption that you must be using qmail if you do use on of these mailbox spools. I, for instance, use postfix with ~/Maildir. mutt, gnus, pine, procmail, postfix all support it fine (although it is a while since I last used pine). I probably missed some programs in this list. All of these programs are DFSG free. Hence all you really need for an /etc/mailsystem config file would be: mboxformat=mbox|maildir location=~/Maildir|~/Mailbox|/var/spool/mail/$USER I don't think the other options are required or needed. However, some way to override these defaults on a per user baisis is important (eg in case a user needs a non-default location for some reason). -- Brian May <[EMAIL PROTECTED]>
Re: Bug#63368: libglide2-v3: Unsatisified Dependancy
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Joseph> device3dfx-source builds device3dfx-module. Since you Joseph> NEED THAT MODULE in order to use Glide for the Voodoo3, Joseph> the dependency BELONGS THERE. It is not my problem that Joseph> the maintainer of that package chooses not to build the Joseph> module for standard kernels. As a system administrator, I am not sure I like the idea of one package depending on kernel modules in this way. I would prefer, no dependencies, but a big warning saying that the module must be installed before it can be used. That way, if I really want the module, I can compile it myself, but if I don't (eg perhaps it is incompatible for some reason with my computer), then I won't have any unexpected surprises. This is what other packages do, eg looking throughout my available file: --- cut --- For diald to work the kernel *must* have SLIP devices, either compiled in or as a module, even if only PPP connections are made. In the latter case you should also have pppd, of course. --- cut --- --- cut --- This package does not contain module binaries. You must build the iBCS module your kernel needs. --- cut --- --- cut -- You WILL need ip accounting in your kernel and at least two ip firewall rules. This version allows you to specify which accounting rule to watch for tx and rx and you will have to enter them in ipfwadm or use the debian package ipac. --- cut --- I do not think it is possible to have dependencies on kernel modules, unlike standard modules, simply because to many different configurations may exist, and it is not possible to tell what may be required by an individual computer/administrator with a static check. However, I would be surprised if no one disagrees with my opinion ;-) (sidenote: perhaps the messages quoted above should have something like "this option is not compiled into the default Linux kernel supplied with Debian. Please see http://.../ for details." The URL could give information on how to compile the kernel and/or the required module. I suggest a http address, and not a local file, and it is highly probably it will need to be updated as new users find more problems). -- Brian May <[EMAIL PROTECTED]>
Re: identical extended descriptions
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: >>> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> Manoj Srivastava wrote: >>> Arguably, the description of these packages should *not* be >>> different, seeing how close they are in packaging. Joey> Right, I don't have a problem with that. People tend to know Joey> what kernel versions mean. (Though it would be easy enough Joey> to stick the kernel version number into the descriptions Joey> too.) Manoj> Yes, it is a 5 word change in the Control file. Do Manoj> you feel it is worth it? I don't thik it makes a meaningful Manoj> distinction (It'll fool the md5sum check, though ;-). Perhaps if the kernel version was included in the short description, then I wouldn't have this problem: ii kernel-image-2 snoopy.1.1 Linux kernel binary image. ii kernel-image-2 snoopy.3 Linux kernel binary image. What upstream version is that? Then again, I do realize this thread was talking about the extended descriptions, not the short description... (also, it could be argued that this is not the best solution). While I seem to remember that alternatives to the dpkg -l command exist, the dpkg -l command is the only one I ever remember when I need it. -- Brian May <[EMAIL PROTECTED]>
Re: /usr/local policy
>>>>> "Anthony" == Anthony Towns writes: Anthony> This argument could also be used to claim that stow Anthony> should have a --no-tree-fold option. Replace `Debian Anthony> packages' with `local packages' doing mkdir, and you've Anthony> got the same problem. When installing local packages, the system administrator would typically install them under /usr/local/stow/packagename, so this is not really an issue. Of course, some packages make this difficult, but that is another (non-Debian) issue. If I mess things up by installing a package in the wrong spot, then it is my fault, and only my fault (although, depending on what happened, I might complain to the upstream author...). If a package that adheres to Debian policy messes things up, then it is the fault of the Debian policy. -- Brian May <[EMAIL PROTECTED]>
Re: /usr/local policy
>>>>> "Anthony" == Anthony Towns writes: >> /usr/local/stow Anthony> Package: stow Description: Organiser for /usr/local/ Anthony> hierarchy GNU Stow helps the system administrator Anthony> organise files under /usr/local/ by allowing each piece Anthony> of software to be installed in its own tree under Anthony> /usr/local/stow/, and then using symlinks to create the Anthony> illusion that all the software is installed in the same Anthony> place. I suspect people don't understand the problems that the current policy has on stow. Just in case, I will spell it out: stow allows you to install packages under /usr/local/stow/package/* For instance, I might have /usr/local/stow/flightgear-0.0/bin /usr/local/stow/flightgear-0.0/lib /usr/local/stow/flightgear-0.0/man (actually I have never installed flightgear, so don't know what directory structure it uses, but am considering it. I don't think any debian package exists. Also, I am making up the version number, 0.0) In the /usr/local/stow directory, I would type in stow flightglear-0.0 this would create the following symlinks (assuming the directories don't already exist): /usr/local/bin ---> /usr/local/stow/flightgear-0.0/bin /usr/local/lib ---> /usr/local/stow/flightgear-0.0/lib /usr/local/man ---> /usr/local/stow/flightgear-0.0/man Then I install xemacs. This would (I think, haven't double checked this though) create the following directory: /usr/local/lib/xemacs/site-lisp After a while, I might want to add files here, eg mailcrypt so I can use gpg with gnus (current Debian versions of mailcrypt that support gpg do not compile for xemacs20). So the obvious thing would be just to put them in the already created directory, ie /usr/local/lib/xemacs/site-lisp/mailcrypt.el So why is this dead wrong? The directory went in the wrong place. Instead of the above location, it really went here: /usr/local/stow/flightgear-0.0/lib/xemacs/site-lisp/mailcrypt.el After I while, I get fed up with flightgear and want to delete it (eg perhaps a Debian version is out by then). So I type: rm -rf /usr/local/stow/flightgear-0.0 and delete my lisp files at the same time. While, yes, I did make a mistake it using existing directory, I think the real problem is that the directory went in the wrong spot in the first place. flightgear doesn't have anything to do with lisp (AFAIK), so having a /usr/local/stow/flightgear-0.0/lib/xemacs/site-lisp directory is completely wrong. However, I would be happy with the proposal to make this a config option. If however, it is judged that this is too complicated (I doubt it), then I would prefer policy specify a file, eg /usr/share/doc/package/local that documents all local directories that the system administrator may use for the package. Then again, I would like this anyway. eg one line for directory: /usr/local/lib/xemacs/site-lisp local lisp files so a system administrator could find all packages that use /usr/local/lib by a simple grep (or egrep) command. (not tested) egrep '^/usr/local/lib' /usr/share/doc/*/local which IMHO is far more useful then the current mechanism anyway. There are probably one million plus one ways to enhance on the above command. -- Brian May <[EMAIL PROTECTED]>
Bug#58759: [Various] Bug#58759: Request for new virtual packages: rsh-client and telnet-client
retitle 58759 [ACCEPTED] Request for new virtual packages: rsh-client and telnet-client thanks ARGGHH!!! How come I can never get this right first go :-( -- Brian May <[EMAIL PROTECTED]>
