Hello, I've seen this new ebuild. Some comments: 1. I think the correct place is sys-libs, not sys-apps. 2. I think you got dependency wrong, please see my example. 3. Never overwrite /etc/reader.conf, you should put configuration at /etc/reader.conf.d and use update-reader.conf. 4. Why don't you add a "serial" use? Most users will use usb... So the default should be usb... Or maybe split into two ebuilds... This will be the best. 5. The configure find the readers directory by it-self, don't specify it, so it will correctly be installed under different conditions. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 72337 [details] asekey-3.0.ebuild This is a sample of ase reader I've written, you can refer to it as base. If you wait a little, I will supply the whole set of ase tools/drivers as ebuilds, when they finish working on them.
Hello, You have done nothing to correct your mistakes. Just be aware that the new sys-apps/pcsc-lite-1.3.0 support ASE-IIIe USB, no additional drivers are needed.
Lars: Alon may become the future maintainer of this stuff. Alon: If you are going to provide a package with the same name (pcsc-ase-iiie-drv) later on, then this should not be dropped (instead just wait until you are able to provide a newer ebuild). If all or most of the functionality is now covered by pcsc-lite and you do *not* intend to have a package in the tree named pcsc-ase-iiie-drv again then it should be OK to remove this. Please clarify.
No. I am going to split it into two packages. I've worked with Athena, and waiting for them to apply a WebDAV with all their software. So this package should be removed.
Created attachment 96768 [details] asedriveiiie-serial-3.2.ebuild
Created attachment 96769 [details, diff] asedriveiiie-usb-3.2.ebuild
(In reply to comment #3) > Lars: Alon may become the future maintainer of this stuff. I have no problems with it. I didn't used it for a long time now... Hmm. Probably I should try again ;-)
(In reply to comment #7) > I have no problems with it. I didn't used it for a long time now... Hmm. > Probably I should try again ;-) What I don't understand is why you ignored all the comments above.
(In reply to comment #8) > What I don't understand is why you ignored all the comments above. No time and no interest.
(In reply to comment #9) > (In reply to comment #8) > > What I don't understand is why you ignored all the comments above. > > No time and no interest. > In this case I would expect such a package will be removed from the tree. Keeping this kind of bug open is not correct.
Alon, That's not really the way we work. Presumably this package is at least partially usable by someone (otherwise it wouldn't have been added to the tree). Removing it would mean removing specific functionality from the distribution -- instead it would be best to wait until you are ready to provide a replacement (and even then you will need to wait a suitable amount of time after the replacement has been provided before removing the original). Removing it would also make it harder for someone else to build on whatever has already been done. The downside is that we end up with some outdated and/or slightly packages in the tree, and a lot of open bugs where the users aren't able to get much done. This is unfortunate and is a hard problem to solve. Lars is a volunteer and is also human (or so he tells us), so it's natural that his interests will change. You will probably experience this in the future: 1 year after adding a package to the tree you will discover you have absolutely no interest in it any more. If you are overloaded with work then it is inevitable that some bugs sink to the bottom of the pile. (herds exist to try and reduce the frequency of this happening -- effectively having a whole group of maintainers. It doesn't always help as most herds are overworked/understaffed...)
(In reply to comment #11) > Alon, > > That's not really the way we work. Presumably this package is at least > partially usable by someone (otherwise it wouldn't have been added to the > tree). I know. And I am glad it was added. But the problem that the ebuild damage the configuration of pcsc-lite. And cause the user to loose all his other readers, or after doing update-reader.conf loose this reader. This what I've noted with I first opened this bug (3). > Removing it would mean removing specific functionality from the > distribution -- instead it would be best to wait until you are ready to provide > a replacement (and even then you will need to wait a suitable amount of time > after the replacement has been provided before removing the original). At 2005-11-06, I just asked to fix the ebuild. This was the day the ebuild was released. > Removing it would also make it harder for someone else to build on whatever has > already been done. I agree... So at least fix current problems. > The downside is that we end up with some outdated and/or slightly packages in > the tree, and a lot of open bugs where the users aren't able to get much done. > This is unfortunate and is a hard problem to solve. Well... This is why people are contributing... They are willing to help in order to solve such bugs. And notice that this bug was opened the day this package was added into portage, so that the mind-set should have been fresh. > Lars is a volunteer and is also human (or so he tells us), so it's natural that > his interests will change. The same day the ebuild is released? > You will probably experience this in the future: 1 > year after adding a package to the tree you will discover you have absolutely > no interest in it any more. I have done this for paying costumers... Never left the costumer with my solution that is not supported, I behave the same in my open-source solutions. The end-user is the most important. > If you are overloaded with work then it is > inevitable that some bugs sink to the bottom of the pile. (herds exist to try > and reduce the frequency of this happening -- effectively having a whole group > of maintainers. It doesn't always help as most herds are > overworked/understaffed...) Again, I do not agree. If there is a major problem in the work, it should be fixed. Overwriting the /etc/reader.conf is a major issue for users. And ignoring bugs opened at the first day the ebuild was added, is not correct approach. Regards.
Those major problems were not described in the original report. To me, it just read like a series of minor deficiencies in the way the ebuild works. It might have helped if this was pointed out earlier on. Granted if this was filed on the day of initial commit then it *should* have been fixed. But again, as this is a volunteer project then nobody is in a position to complain. If you want to patch the existing ebuild to fix the problem where it overwrites configuration from another package, I'm sure we could persuade Lars to commit it. That's the major issue at hand, right? Then later on we can replace the ebuild completely with your newer work.
Hello treecleaners, Please remove from tree. Users should use: app-crypt/asedriveiiie-usb app-crypt/asedriveiiie-serial Nothing stable... So I think it can be done quite fast... Thanks!
metadata has pylon, CCing him. Alon, TreeCleaners is only punting maintainer-needed stuff these days; I've CC'd pylon in case he wants to take care of the package. Otherwise rewrite the metadata.xml to maintainer-needed and it will get our on review list. Generally we only punt broken packages though. We seem to be getting a lot of requests for 'stop using package A and use B instead' but I'd like the maintainer/herd to take care of those if possible.
I'm fine with removing this ebuild and use asekey instead, as this seems to be the better ebuild.
(In reply to comment #15) > Alon, TreeCleaners is only punting maintainer-needed stuff these days; I've > CC'd pylon in case he wants to take care of the package. > > Otherwise rewrite the metadata.xml to maintainer-needed and it will get > our on review list. Hmmm... If I put in in maintainer-needed someone may take it... :) > Generally we only punt broken packages though. We seem to be getting a > lot of requests for 'stop using package A and use B instead' but I'd like the > maintainer/herd to take care of those if possible. Oh.... I did't know that... I thought only you can remove stuff from the tree. So can I just remove it from tree my-self?
(In reply to comment #17) > (In reply to comment #15) > > Alon, TreeCleaners is only punting maintainer-needed stuff these days; I've > > CC'd pylon in case he wants to take care of the package. > > > > Otherwise rewrite the metadata.xml to maintainer-needed and it will get > > our on review list. > > Hmmm... If I put in in maintainer-needed someone may take it... :) > hehe ;) > > Generally we only punt broken packages though. We seem to be getting a > > lot of requests for 'stop using package A and use B instead' but I'd like the > > maintainer/herd to take care of those if possible. > > Oh.... I did't know that... > I thought only you can remove stuff from the tree. > So can I just remove it from tree my-self? > LOL, how could I enforce something that silly :) A while back I said 'if you want a package gone you can assign it to TreeCleaners' but we changed policy a few weeks ago, mostly I think because its better for herds to take care of their own packages, and TreeCleaners itself can spend more time looking at the unmaintained stuff. Maintainer-needed and TreeCleaners was my original intention and it got out of hand. So in short, yes you can absolutely remove it yourself :)
(In reply to comment #18) > So in short, yes you can absolutely remove it yourself :) OK... So that you won't be angry with me... 1. Post a message to gentoo-dev. 2. Wait for a week. 3. Remove from tree. Right?
(In reply to comment #19) > (In reply to comment #18) > > So in short, yes you can absolutely remove it yourself :) > > OK... So that you won't be angry with me... > 1. Post a message to gentoo-dev. > 2. Wait for a week. > 3. Remove from tree. > > Right? Not if you p.mask it first ;)
To clarify, here's the process I would follow: - Post to gentoo-dev, stating that it will be added to package.mask in 48 hours and removed after 2 weeks, also be sure to state the upgrade path or replacement packages - After 2 days, put it in package.mask, with similar info as above - After 2 weeks, remove it from tree and delete the mask entry treecleaners is a relatively new project which focuses on just a few specific areas -- removing packages has historically been the responsibility of the maintainer/herd and will probably stay this way for some time to come.
(In reply to comment #21) > treecleaners is a relatively new project which focuses on just a few specific > areas -- removing packages has historically been the responsibility of the > maintainer/herd and will probably stay this way for some time to come. Treecleaners have no plans to change this, we only want to touch maintainer-needed packages.
